问题描述
虽然显然不是所有的场景都可以被单一的设计覆盖，但现在通常觉得ORM类应该在演示文稿和业务层（本地或远程）之间来回传递，代替了对数据传输对象的需求？就我所见，使用ORM类提出了不必要的加载加载，上下文管理问题和紧耦合的问题，也节省了大量的时间并保持简单。现在是否有一种标准的方法，通常比较适合（对于大多数情况）？这很有趣问题和一个我在两年过去一直在调查和试验。
我认为这里真的没有正确或错误的答案。我不认为你只能说我想要一个，因为通常你可能想要一个混合，取决于你的客户是什么（网页，ws，机器和/或本地，远程）。
这里要记住的重要事情是每个产品的优缺点是根据您的要求进行应用。
例如： / p>
- 如果您使用SEAM，那么您将希望避免使用分层架构，因为您可以访问扩展的持久性上下文。没有这种支持的其他网络技术往往会更好地与预先准备状态的DTO一起工作。
- 如果要发送远程消息，导入的东西是保持轻薄，DTO通常比富域对象更好地工作。在这里，您可以透明地抑制任何ORM问题/行为。
- DTO模式有利于保护您的客户端免受域更改。如果您的应用程序是Web服务，则具有域（实体）对象，如果您的应用程序定义了您的合同，那么这一点尤其重要。
通过将您的系统层叠并仔细地将其保护起来，您可以为许多不同类型的客户端生成各种API。
Although obviously not all scenarios can be covered by a single design, is it generally felt now that ORM classes should be passed to and fro between the presentation and business layer (either local or remote), replacing the need for data transfer objects? As far as I can see, using ORM classes presents problems of unnecessary eager loading, context management issues and tight coupling, but also saves a great deal of time and keeps things simple. Is there now a standard approach that generally favours one over the other (for the majority of situations)?
This is very interesting question and one I have been investigating and experimenting with over the pass two years.
I think there really is no right or wrong answer here. I don't think you can simply say I want one over the other because typically you may want a hybrid depending on what your clients are (webpage,ws,machine and/or local,remote).
The important thing to remember here is what the pros and cons are to each offering and applying this based on your requirements.
For Example:
- If you were using SEAM, then you would want to avoid a heavily layered architecture because you have access to an extended persistence context. Other web technologies without this support tend to work better with a DTO which prepared the state upfront.
- If you are sending a remote message the import thing is to keep it thin and lightweight, a DTO would typically work better here than a rich domain object. Here you can suppress transparently any ORM issues/behavior.
- DTO pattern has the benefit of protecting your clients from domain changes. This is particularly important if your app is a web service, having a domain (entity) object which defines your contract might leave you unstuck at some point.
By wrapping your system in layers and carefully exposing and securing them, you can produce various APIs for many clients of different types.
这篇关于在ejb3中使用数据传输对象被认为是最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！