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

Question

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

以下是我知道要考虑的一些事情：

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

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

我看到有人建议从 STE 开始，并且仅在出现问题时才实施 DTO，但是我们目前已经有了 DTO，并且正在尝试确定使用 STE 是否会使生活更轻松。我们在这个过程中已经足够早了，切换不会花费太长时间，但我不想切换到 STE，只是发现它对我们不起作用并且必须将所有东西都切换回来。

Answer 1

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

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

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

• 数据的客户端查询服务器
• 服务器查询 EF 并接收一组 STE 并将它们返回给客户端
• 客户端使用 STE，修改它们并将它们发送回服务器
• 服务器接收 STE 并将传输的更改应用到 EF => 数据库

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

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

任何其他情况只是意味着您没有利用自我跟踪能力，也不需要它们。

您的其他要求呢？

• 用户可以定义自己的接口，因此 WCF 服务所需的数据会根据用户为他们定义的接口而变化。

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

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

我不确定您希望如何实际实现这一目标。 STE 不使用投影，因此您必须直接在实体中为空字段。请注意，您必须在实体未处于跟踪状态时执行此操作，否则您的掩码将保存到数据库中。

• 数据库层向多个服务器/数据库发送垃圾邮件

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

STE 是变更集模式的实现。如果您想使用它们，您应该遵循它们的规则以充分利用该模式。如果使用得当，它们可以节省一些时间，但这种速度的提高伴随着一些架构决策的牺牲。与任何其他技术一样，它们并不完美，有时您会发现它们很难使用（只需关注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 开发非常吻合。