DTO和实体框架

本文关键字：框架实体 DTO | 更新日期: 2023-09-27 18:20:49

我的解决方案使用实体框架，我将EF模型转换为DTO对象，以便从UI层上下传递。

但我有一个设计问题：我有一张Person表和一张PersonUnavailibility表。一个人可能会有一段时间无法联系。

我的PersonDTO对象具有PersonEF模型的所有属性，还有一个List<PersonUnavailibilityDTO>对象。所以，当我得到我的人时，我也得到了人的无效期。

但是，我的PersonUnavailibilityDTO应该有一个PersonDTO对象吗？所以，如果我得到一个PersonUnavailibilityDTO对象，我可以看到它与哪个人有关？

如果是的话，我会得到一个循环参考。我的PersonUnavailibilityDTO's Person属性，有一个他所有PersonUnavailability行的列表。。。每个都有一个PersonDTO，每个都有…的列表。。。。等等

这种东西最好的设计是什么？是否只包括与父对象相关的子对象？

也就是说，只有PersonDTO有PersonUnavailibilityDTOs的列表，但PersonUnavailibilityDTO没有PersonDTO？

DTO和实体框架

这取决于情况。

在大多数情况下，这是不需要的，因为您将从人员视图查看dto，并且不可用的内容总是通过人员访问的。

但是，当你以另一种方式访问你的对象时，有必要将此人添加到不可用状态。

试着让你的Dto尽可能地小而简约。

一种可能的方法是使用一个通用的复合dto模型来承载所有可能的实体组合。

http://netpl.blogspot.com/2010/12/generic-dto-model-and-other-silverlight.html

以失去严格的结构为代价，你可以得到一个可重复使用的结构。

一般建议，最好避免对象之间的双向关系。

风险在于对象不同步，即对象A指向B（或B的集合），但B不指向A——通常，它会有一个空引用。为了防止这种情况发生，你必须始终保持关系的两端同步，这是有代价的。

然而，当对象是不可变的（DTO可能就是这样）时，这一点会得到缓解，因为它们是在创建时组成的，之后再也不会修改，从而消除了它们之间存在差异的风险。

正如Jeroen所指出的，我仍然建议使用最简单的解决方案：PersonDTO -> PersonUnavailibilityDTO，直到明确证明您需要反向关系。

我更喜欢从DTO中删除集合，并添加服务方法来请求集合：

function GetUnavailable(PersonID, Options) as IEnumerable(of PersonUnavailabilityDTO)

这种方式