在 List 或 DropdownList 中加载 Value 对象，DDD
我需要澄清一些事情。
有人员聚合，2 个 VO（国家、州、省）。
我想在我的表示层中加载所有国家/地区（我正在使用 mvc）
Evan 说您只使用存储库（IPersonRepository）来处理根实体（它应该始终返回对聚合根的引用）
public interface IPersonRepository()
{
void savePerson(Person p);
void removePerson(Person p);
Ilist<Person> getPerson();
}
我通常会做什么来解决这个问题：
在 IPersonRepository 中添加此方法
IList<Country> LookupCountrysOfPerson();
在基础层中实现域接口，如下所示：
public IList<Person> LookupCountrysOfPerson()
{
return Session.CreateQuery("from Countrys").List<Person>());
}
我的伙伴说我错了。
有时您必须牺牲域模型才能完成某些任务，
最好的方法是什么？
请附上代码！ :)
I need to clarify something.
Have Person Aggreagate , 2 VOs (Country, StateProvince).
I want to load all country in my presentation layer (i am using mvc)
Evan says you only use repository (IPersonRepository) to work with root entity (it should always return just a reference to the Aggregate Root)
public interface IPersonRepository()
{
void savePerson(Person p);
void removePerson(Person p);
Ilist<Person> getPerson();
}
what i usually do to solve this :
Add in IPersonRepository this method
IList<Country> LookupCountrysOfPerson();
In Infra layer implement the Domain interfaces like this:
public IList<Person> LookupCountrysOfPerson()
{
return Session.CreateQuery("from Countrys").List<Person>());
}
My partner says im wrong.
Sometimes you have to sacrifice your domain model in order to accomplish some task
What is the best way to do this?
with code please! :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想说你不太可能需要国家作为一个实体。我怀疑国家只不过是参考数据，就像一个人的头衔一样。您所在域中是否存在与国家/地区相关的行为？我怀疑这只是打印在信件/信封上的内容。
这个问题有点类似于我不久前回答的这个问题：
简单聚合根和存储库问题
我的建议是您实现一个查找服务，您的客户端可以使用该服务并对其进行缓存。忽略 DDD 的规则以及与聚合或存储库相关的任何内容。正如其他人提到的，这就是 CQRS 的意识形态发挥作用的地方；客户端不必通过域来获取数据。该域纯粹是事务性的，不是为查询而设计的。
本文介绍了如何为通常填充 UI 中下拉列表的内容（即标题、国家/地区等）的参考数据构建通用查找服务
http://wtfpermillion.blogspot.com/2011/02/working-with-reference-data-lookups.html
I would say it's unlikely that you need country to be an entity. I suspect that country is nothing more than reference data, much like a person's title would be. Is there any behavior associated to country in your domain? I suspect it's just what's printed onto letters/envelops.
This question is somewhat similar to this one which I answered a while back:
Simple aggregate root and repository question
My suggestion is that you implement a Lookup service that your client can make use of and which is cached. Ignore the rules of DDD and anything to do with aggregates or repositories for this. As someone else has mentioned, this is where CQRS's ideology comes into play; the client shouldn't have to go through the domain in order to get data. The domain is purely transactional, not designed for queries.
This article explains how to build a generic lookup service for reference data for things that typically fill dropdowns in the UI (i.e. Title, Country etc)
http://wtfperminute.blogspot.com/2011/02/working-with-reference-data-lookups.html
埃文斯还说（第 170 页）“像位置这样基本的实体可能会出于多种原因被许多对象使用......”
出于上述原因，我还会考虑将 Country 设为实体。也许更重要的是，它是一个低级对象。您甚至可能还通过配置而不是通过任何实际的域活动来提供国家/地区。因此，我会将其从 Person 中删除并使其成为一个独立的实体。
此外，对于这种类型的对象，您可能并不真正需要专用存储库，请考虑创建一个查找服务，为一组具有这种性质的类似对象提供查询访问。
Evans also says (pg 170) "An entity as basic as Location may be used by many objects for many reasons..."
I would also consider making Country an entity for the reasons given above. Perhaps more importantly, it is a low level object. You probably are also even supplying Country by configuration rather than through any actual domain activities. Therefore I would remove it from the Person and make it a standalone entity.
Also for this type of object you may not really need a dedicated repository, consider creating a single lookup service that provides query access for a group of similar objects of this nature.
如果您的域国家/地区实际上是一个VO（您不想在国家/地区名称更改等中维护身份线程），这是最常见的情况，我会在数据访问层中添加一个专门的类来返回所有国家/地区作为 VO 的列表。我还将向国家/地区实体添加缓存（NHibernate 中的二级缓存）并列出所有国家/地区查询，这样我就不必每次都访问数据库。
事实上，这才是 CQRS 真正的亮点。 CQRS 承认您不必通过域层来获取一些用于演示目的的数据。在 CQRS 中，您只需获取一些数据。
If in your domain country is actually a VO (you don't want to maintain a thread of identity in the country name was changed etc.) which is the most common scenario, I would add a specialized class in the data access layer to return a list of all countries as VOs. I would also add caching (2nd level cache in NHibernate) to the country entity and list all countries query so that I don't have to hit the DB each time.
Actually, this is where CQRS really shines. CQRS acknowledges that you don't have to go through the domain layer in order to get some data for presentation purposes. In CQRS you just grab some data.
听起来国家实际上并不是这里的价值对象；他们具有不同的身份，并且对于
Person对象之外的业务目的非常重要。他们应该成为实体，并以适合他们的方式对待。可以这样想：假设某个动荡的国家现任独裁者被推翻并更名。
Person对象对Country的引用应该仍然有效，因为Country不是由其属性（即表示其名称的字符串）定义的，但通过其身份。It sounds like countries are not in fact value objects here; they have distinct identities and are important for business purposes outside of your
Personobjects. They should become entities, and be treated in the fashion appropriate to them.Think of it this way: let's say some volatile country had their current dictator overthrown and got a name change. The
Personobject's reference to aCountryshould still be valid, because theCountryis not defined by its attributes (i.e. the string denoting its name), but by its identity.