我有2个业务实体（对象）：产品和订单。 Product对象除了一些其他属性外，还包含一个“Name”属性。订单实体除了指向产品的属性（假定为了简单起见，只能有一个产品），还包含“Id，Date ...等”属性将对象成员添加到OOD中的业务实体
在我的情况下，当我想要要显示订单列表，我想显示每个订单的产品名称，但我不需要显示其他产品的属性。
我的问题是，当我设计Order实体类时，我应该添加一个指向Product的属性，还是我应该简单地添加一个名为“ProductName”的属性？如果答案是添加一个指向Product的属性，那么只加载Name属性还是我应该填充所有其他属性（从数据库检索数据时）？
我也很感激它，如果你可以添加与你的答案一些文章的链接。
您的问题似乎有一个假设，即order-display thingie必须与订单实体1-1匹配。
我认为你已经为自己挖了一个洞，试图简化为每个订单一个产品。
如果您有一个连接表（OrderProducts？或更好的OrderLines），那么订单和产品实体都不必“知道”彼此 您可以保持这些清洁和简单，并将此DisplayOrders函数委托给新加入的实体。
也许，如果我假装成顾客，说我想要的订单显示，以不再显示产品名称，而是显示总订单价值。
这将是一个很大的正在调整的你实体，如果你与这个1-1匹配的想法保持一致，你的分贝也是。
不要去那里。变化是一个给定的。 ip 评论后...
如果它确实是一个1 - 1的关系，那么你不需要两个实体。 1-1将是每个订单一个产品，并且每个产品一个订单。
我做了愚蠢的假设你的问题，实际上你可以有一个产品订购了很多次。
因此，大多数有趣的方法（除了两个实体上的基本问题）都基于两个实体之间的关系。这是你应该建模的领域的一部分。
更多评论...之后
我从来没有denormalise除非我优化性能，和我做“最后的”如果我没有更好的选择。
如果您正在讨论需要从属对象的一个属性，我会立即创建实体，并将publisherid放在书实体上。
我会这样做的假设，发布者实体的名称属性可能会改变。非规范化意味着我将不得不捕获对发布者名称的更改，通读所有书籍并更改其名称。更糟的是，这里还有一个隐藏的假设，那就是发行商的名字是独一无二的。现在你可能会这样做了，但为了避免一个用户的一些嘘声给两个发布者同名的问题，以避免一个真正可怕的bug，你必须执行它。
在这个有意限制的例子之外的现实世界里，我希望有一些功能分配给伪实体BookListItem（例如选择读取列表或购物车），但我会被第三个第一类实体BookListItem，或许还有第四个BookList。
所有的设计都是妥协，如果你打算很多地看书的名单，并且出版商的名字将在蓝月亮作业中一次出现，并且你准备好了解身份问题，并且你可以预见没有改变这种行为，那么denormalising是一个很好的妥协。
在某些方面，对于您的问题没有正确的答案，您需要清楚的是您的设计允许/启用以及它施加的限制，例如， PublisherName的是独一无二的，这是无处在的要求，可能会导致您的客户打电话给你不同的名字....
HTHS
感谢您的回答。恐怕在Order和Product中提出我的问题使得这个问题具有误导性和不明确性。请尝试再次重新阅读，但不是订单，而是将其替换为“Book”而不是Product，将其替换为“Publisher” – user2931442
再一次注意：请不要假设问题中未列出的任何内容。关于我的问题的整个想法是关于何时有2个具有1-1关系的DB表，以及我们需要如何在类中表示它们。他们应该如何在课堂上互相引用？ – user2931442
如果他们有1-1的关系，为什么两个班！有一个不存在的假设。用这个问题你可能会对程序员更好。现在更多讨论。 –
这只是一个CQRS的问题。要显示与UI相关的任何内容，只需让查询处理程序（服务）直接从db（持久性）获取所需的视图模型数据，以便Business/Domain层被跳过。就这样。 您不应该根据UI需求设计您的商业模式。
当处理改变业务模型的状态时（命令 CQRS的一部分），设计应该反映概念及其关系。在您的情况下，订单参考一个或多个使用其ID的产品。此模型不应用于查询，仅用于创建/更新。
要查询事情，根据您的持久性实现，您可以使用现有的db数据或在域状态更改时自动创建的用例相关读取模型（通过域事件处理程序）（但这是更复杂的情况，取决于正确的域事件设计，基于消息的体系结构和不易查询的存储）。
感谢您的回答。虽然答案并没有直接回答我的问题，但他们在这个问题上大开眼界。谢谢 – user2931442
但我只能选择一个答案 – user2931442