是否应该使用实体 Bean 作为域模型
鉴于 Java EE 世界中的新改进导致大量设计模式被弃用，DTO 基本上不受欢迎。
但是，我不希望数据库的关系结构决定客户端（Web 应用程序）如何使用我的 EJB 中的服务。由于技术的发展方式，我认为随着光纤技术和其他不可想象的技术成为现实，我们将在大约 5 年内完成对 UI 进行彻底改革的工作。所以我希望业务逻辑能够完全封装，以便我们可以随时轻松更改 UI。
考虑到这种想法，我正在开发一个纯 API 来表示业务模型和服务，以便客户端可以使用它。
然而，我必须一直编写转换器来将实体 bean 转换为该 API。这是正确的做法还是过度工程化了？
非常欢迎您的反馈和意见。
注意。该项目使用完整的 Java EE 6 平台
given the deprecation of loads of design patterns because of the new improvements in the Java EE world, DTO's are largely frowned upon.
However, I dont want the relational structure of database to dictate how the client(web app) uses the services in my EJB. Because of the way technology evolves, I see work being done in about 5 years time in trying to overhaul the UI as fibre optic technologies and other unthinkables becoming a reality. So i want the business logic to be completely encapsulated to allow easily changing the UI whenever we want.
With this thinking in mind, i am developing a pure api to represent the business model and services so the client can use that instead.
However, I'm having to write converters all the time to convert the entity beans to this API. Is this the right thing to do or am over engineering.
Your feedback and opinion largely welcomed.
NB. This project uses the full Java EE 6 platform
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于最佳的处理方式存在着相互冲突的“宗教”。我和你一样，更喜欢面向对象的解决方案，这意味着数据库行（实体）不等于业务域对象。那么，该怎么办呢？
我建议使用典型的工具（例如 Hibernate 或 Spring）来填充持久层中的实体。然后，使用代理在数据库和域层类/对象之间移动状态。
HTH，马克
There are conflicting "religions" about the best way to proceed. I, like you, prefer more object-oriented solutions, which means that DB rows (entities) are not equal to business domain objects. So, what to do?
I'd recommend using your typical tooling, e.g. Hibernate or Spring, to populate entities in your persistence layer. Then, use brokers to move state between the DB and the domain layer classes/objects.
HTH, Mark