领域模型和实体模型是否相同
我有基于 DDD 概念开发的领域模型，几乎是面向对象的，并且其中既有状态又有行为。问题是为了使用 Hibernate，所有持久属性都必须有 getter 和 setter。这没有吸引力，因为我不想为我的域对象的某些属性引入设置器。我是否应该将域对象映射到 DTO，其唯一目的是仅维护数据。
I have domain model developed based on DDD concept, pretty much Object Oriented and have both state and behaviors in it. The problem is in order to use Hibernate all the persisting attributes has to have getters and setters. This is not appealing since I don't want to introduce setter for some attributes of my domain objects. Should I map my domain object to DTO instead, which sole purpose is to have maintain just the data.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，这两个概念是相同的。领域模型用于从问题域（即用于解决特定问题或一组问题的信息）的角度描述对象的模型，实体模型用于从问题域的角度描述对象的模型。参与者系统的观点（在许多情况下，这是一些使用模型来解决问题并对实体进行操作的应用程序）。
所以，一般来说，它们是同一件事。
也就是说，Hibernate非常灵活，并且一般来说，不需要您对持久对象结构做太多事情。关键在于如何定义映射。无论如何，我不建议使用 DTO 来处理数据的持久化。 Hibernate 在内部使用代理来完成这一切……这就是它的工作。添加更多的类只会增加应用程序的复杂性，并没有真正提供太多好处。更多的复杂性几乎从来都不是一件好事。
使用 Hibernate，您可以拥有私有 setter，或者让 Hibernate 仅对字段进行操作并完全忽略 getter/setter。在第一种情况下，您仍然引入了 setter，但它是私有的，因此不会影响类的公共 API。通过字段访问，Hibernate 不需要任何属性的 getter 或 setter，但它也绕过了您可能必须执行其他操作的任何逻辑，例如设置瞬态（非持久化）对象的属性。
通读 Hibernate 手册，尤其是有关映射的部分。它是一个非常灵活的 ORM，不会对您造成任何不必要的限制。
In general, the two concepts are the same. A domain model is used to describe the model of your objects from the viewpoint of the problem domain (ie. the information used to solve a particular problem or set of problems) and an entity model is used to describe the model of your objects from the viewpoint of a system of actors (in many cases, this is some application that uses the model to solve problems and acts on the entities).
So, in general, they are the same thing.
That said, Hibernate is very flexible and in general, doesn't require you to do much of anything with your persisted objects structure. The key is all in how you define the mappings. In any case, I would not suggest having a DTO just to deal with persisting the data. Hibernate does that all internally using proxies...that's it's job. Adding more classes just adds to the complexity of your application and doesn't really provide much benefit. More complexity is almost never a good thing.
With Hibernate, you can have private setters, or have Hibernate only operate on the fields and ignore the getters/setters completely. In the first case, you are still introducing a setter, but it is private and so it doesn't impact the public API of the class. With field-access, Hibernate doesn't need there to be any getter or setter for a property, but it also goes around any logic you may have had to do other things, like set transient (non-persisted) properties on your objects.
Have a read through the Hibernate manual, especially on the section about mapping. It is a really flexible ORM that doesn't restrict you any more than it has to.