NHibernate：为什么要使用？超过<一对多>映射集合
使用 NHibernate 时，在什么情况下您会选择使用复合元素来映射集合以提供值对象的集合，而不是创建完整的实体并使用一对多来映射它？
您可能有一个值类型类“PostalAddress”来表示地址。如果您有一个人员实体，并且每个人可以有许多地址，您可以像这样映射此关系（选项 1）：
<bag name="Addresses" table="PersonAddress">
<key column="PersonID"/>
<composite-element class="PostalAddress">
<property name="StreetAddress"/>
<property name="Town"/>
<property name="City"/>
<property name="Postcode"/>
</composite-element>
</bag>
或者您可以创建一个实体“PersonAddress”，其中包含“PostalAddress”类型属性，并使用一对多关联（选项 2）：
<bag name="Addresses">
<key column="PersonID"/>
<one-to-many class="PersonAddress"/>
</bag>
<class name="PersonAddress">
<id name="Id">
<generator class="native"/>
</id>
<component name="Address" class="PostalAddress">
<property name="StreetAddress"/>
<property name="Town"/>
<property name="City"/>
<property name="Postcode"/>
</component>
</class>
有什么理由不执行选项 1？ PersonAddress 表有一个 ID 列这一事实是否表明它本身应该是一个实体，因此使用选项 2？
When using NHibernate, under what circumstances would you choose to map a collection using a composite-element to give a collection of value objects, rather than creating a full-blown entity and mapping it using one-to-many?
You might have a value-type class 'PostalAddress' to represent an address. If you had a person entity and each person could have many addresses you could map this relationship like this (Option 1):
<bag name="Addresses" table="PersonAddress">
<key column="PersonID"/>
<composite-element class="PostalAddress">
<property name="StreetAddress"/>
<property name="Town"/>
<property name="City"/>
<property name="Postcode"/>
</composite-element>
</bag>
Or you could create an entity 'PersonAddress' which has a 'PostalAddress' typed property on it and map the addresses with a one-to-many association (Option 2):
<bag name="Addresses">
<key column="PersonID"/>
<one-to-many class="PersonAddress"/>
</bag>
<class name="PersonAddress">
<id name="Id">
<generator class="native"/>
</id>
<component name="Address" class="PostalAddress">
<property name="StreetAddress"/>
<property name="Town"/>
<property name="City"/>
<property name="Postcode"/>
</component>
</class>
Are there any reasons not to do option 1? Does the fact that the PersonAddress table has an ID column suggest that it should be an entity itself, hence use option 2?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
<复合元素>适用于当您有一组值时，而则适用。是实体的集合。实体的定义特征是唯一标识符。因此，如果您的收藏中的项目有 PK，请使用<一对多>。否则使用。
另一种思考方式是如何确定平等。您是否通过比较 ID 或验证所有属性是否相同来确定相等性？例如，在您的应用程序中，两个对象是否表示相同的地址 if (address1.Id == address2.Id) 或 if (address1.Street == address2.Street && address1.City == address2.City && ETC。）？没有通用的正确答案，因为它取决于应用程序上下文。在许多情况下，金钱是一种价值对象。无论你有这 20 美元还是那 20 美元，都没关系。只有金额是相关的。如果您正在为造币厂编写跟踪应用程序，他们可能需要知道您正在处理哪张 20 美元钞票，并且您需要跟踪 20 美元钞票上的序列号。在这种情况下，金钱是一个实体。这一切都取决于应用程序和上下文......
<composite-element> is for when you have a collection of values whereas <one-to-many> is a collection of entities. The defining characteristic of an entity is a unique identifier. So if the items in your collection have a PK, use <one-to-many>. Otherwise use <composite-element>.
Another way to think about it is how you determine equality. Do you determine equality by comparing an ID or by verifying that all properties are identical? e.g. In your application, do two objects represent the same address if (address1.Id == address2.Id) or if (address1.Street == address2.Street && address1.City == address2.City && etc.)? There is no universal right answer as it depends on application context. In many cases, money is a value object. Whether you have this $20 or that $20, it doesn't matter. Only the amount is relevant. If you were writing a tracking application for a mint, they probably need to know which $20 bill you're dealing with and you would track the serial number on the $20 bill. In this case, money is an entity. It all depends on application and context...