域对象行为如何
这是一个来自新手的相当愚蠢但完全有效的问题。 上下文：我的“域对象”有一个名称（和一些其他属性，但它们并不重要）。该名称是根据数据库中定义的一些模式生成的。 现在...谁应该确定域对象的名称？域对象是否应该确定它自己的名称（请注意，这个“名称”可以基于它自己或其他对象的属性），或者服务应该根据模式确定名称，然后调用类似
domainObject.setName(theActualName)
我倾向于遵循“服务”的名称”方法，但另一方面，这项任务似乎应该是特定于对象的行为。
非常感谢您的回复。
Here's a rather dumb but perfectly valid question coming from a newbie.
Context: My "domain object" has a name (and some other attributes, but they are not important). This name is generated according to some patterns which are defined in the database.
Now... who should determine the name of the domain object? Should the domain object determine it's own name (please note this "name" can be based on it's own or some other object's attributes) or should a service determine the name according to the pattern and then call something like
domainObject.setName(theActualName)
I tend to follow the "service" approach, but on the other hand it seems this task should be an object-specific behaviour.
Thanks a lot for your replies.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为你应该看看告诉不要问原则
如果对象包含它的所有数据需要计算它的名称我会将此方法放在该类上。如果这个数据是基于其他对象的属性并且父类也包含这个包含数据的子对象，我会再次放在父类上。
保持简单即可。如果我真的不需要，我不会引入服务类。用 DDD 术语来说，您应该将域相关逻辑放在域类中。
I think you should look at Tell Don't Ask Principle
If object contains all the data it needs to calculate its name I would put this method on that class. If this data is based on other object's attributes and parent class also contains this child object that contains data, I would again put on the parent class.
Just Keep it simple. I wouldn't introduce a service class if I dont really need. In DDD terms you should put your domain related logic in domain classes .
这是一个包含逻辑的领域对象？如果是的话，我宁愿给它一个 DAO 的引用，并让它自己决定它的名字。这样你的逻辑就会接近你的数据。
This is a domain object that contains logic? If yes, I'd rather give it a reference to DAO and let it decide its name on its own. In this way your logic will be near your data.
有几个问题与此相关：
如果域对象无论如何都要与数据库绑定，并且不需要集中管理名称，那么我认为拥有域对象名称本身会带来更大的 对象内聚。
A couple of issues bear on this:
If the domain objects are going to be tied to the data base anyway, and if there is no need to centrally manage the names, then I would think that having the domain objects name themselves leads toward greater object cohesion.