我怎么知道我是否应该使用自我跟踪实体或DTO / POCO？

Question

关于我们的设计，我可以问自己有哪些问题，以确定我们是否应该在我们的应用程序中使用DTO或自我跟踪实体？

以下是我所知道的一些事项：

• 我们有一个带有WPF / MVVM客户端，WCF服务器和MS SQL数据库的标准n层应用程序。
• 用户可以定义自己的界面，因此WCF服务所需的数据会根据用户为自己定义的界面而变化
• 在客户端和服务器端都使用模型进行验证。我们不会直接约束DTO或STE
• 某些模型包含从WCF服务延迟加载的属性（如果需要）
• 数据库层阻止多个服务器/数据库
• 服务器端存在权限检查，这会影响数据的返回方式。例如，根据用户的角色部分或完全屏蔽某些数据
• 我们的资源有限（时间，人力等）

那么，我怎样才能确定哪些适合我们？我之前从未使用EF，所以我真的不知道STE是否适合我们。

我见过人们建议从STE开始并且只有在它成为问题时才实施DTO，但是我们目前有DTO并且正在尝试决定使用STE是否会让生活变得更轻松。我们在这个过程中已经足够早，切换不会花费太长时间，但我不想转换为STE只是为了发现它对我们不起作用并且必须切换回来。

Answer 1

如果我了解您的架构，我认为它对STEs不利，因为：

• 在客户端和服务器端都使用模型进行验证。我们不会直接约束DTO或STE

主要优势（和唯一优势）或STE是他们的追踪能力，但只有在双方都使用STE时跟踪能力才有效：

• 数据的客户端查询服务器
• 服务器查询EF并接收一组STE并将它们返回给客户端
• 客户端使用STE，修改它们并将它们发送回服务器
• 服务器接收STE并将转移的更改应用于EF =＆gt;数据库

简而言之：客户端或服务器端没有其他型号。要充分利用STE，他们必须：

• 服务器端模型（=无单独模型）
• 在WCF中转移数据（=无DTO）
• 客户端模型（=没有单独的模型，直接绑定到STE）。否则，在处理有界对象上的更改事件和修改STE时，您将复制跟踪逻辑。 （客户端和服务器与STE共享程序集）。

任何其他场景只是意味着您没有利用自我跟踪能力而您不需要它们。

您的其他要求如何？

• 用户可以定义自己的界面，因此WCF服务所需的数据会根据用户为其定义的界面而变化。

这可能是可能的，但要确保每个“延迟加载”部分是单独的结构 - 不要在客户端构建复杂的模型。我已经看到了一些问题，人们不得不将整个实体图发回给更新，这不是你一直想要的。因此我认为你不应该将加载的部分连接到单个实体图形中。

• 服务器端存在权限检查，这会影响数据的返回方式。例如，根据用户的角色部分或完全屏蔽某些数据

我不确定你想如何实现这一目标。 STE不使用投影，因此您必须直接在实体中使用空字段。请注意，当实体未处于跟踪状态或您的屏蔽将保存到数据库时，必须执行此操作。

• 数据库层阻止多个服务器/数据库

这不是STE的问题。服务器必须使用正确的EF上下文来加载和保存数据。

STEs是变更集模式的实现。如果您想使用它们，您应遵循其规则以充分利用该模式。如果使用得当，它们可以节省一些时间，但这种加速会牺牲一些架构决策。与其他任何技术一样，它们并不完美，有时您会发现它们难以使用（只需按self-tracking-entities标签查看问题）。他们也有一些serious disadvantages但在.NET WPF客户端你不会遇到它们。

Answer 2

您可以为给定方案选择STE，

• 所有STE都是POCO，。Net动态添加一层进行变更跟踪。
• 使用T4模板生成STE，它将节省您的时间。
• Automapper等工具的使用将节省您的时间手动将WCF返回的数据合同转换为实体或DTO

STE的优点 -

1. 您不必手动跟踪更改。
2. 如果是WCF，您只需要说applydbchanges，它就会自动刷新实体

STE的缺点 -

1. 由于动态跟踪，STE比POCO更重

POCO的优点 -

1. 重量轻
2. 可以轻松与EF或nH桥接

POCO的缺点 -

1. 需要使用EF手动跟踪更改。（痛苦）

Answer 3

POCO是动态代理的，并且在线see this MSDN article for the workaround though上不能很好地发挥作用。所以他们可以做到但IMO你最好去STE，因为我相信它们与WPF / MVVM开发很好地配合。