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

Question

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

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

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

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

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

Answer 1

如果我理解你的架构，我认为这对 STE 因为：

• 模型在客户端和服务器端均用于验证。我们不会直接绑定到 DTO 或 STE STE 的

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

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

简而言之：客户端或服务器端没有额外的模型。要充分利用 STE，它们必须是：

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

任何其他情况仅意味着您没有利用自我跟踪功能，并且您不需要它们。

那你的其他要求呢？

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

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

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

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

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

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

STE 是变更集模式的实现。如果您想使用它们，您应该遵循它们的规则以充分利用该模式。如果使用得当，它们可以节省一些时间，但这种加速会牺牲一些架构决策。与任何其他技术一样，它们并不完美，有时您会发现它们很难使用（只需遵循 self-tracking-entities< /a> 标签查看问题）。它们也有一些严重的缺点，但在 .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 是动态代理，在线上运行效果不佳 请参阅此 MSDN 文章了解不过解决方法。所以它们可以被制作，但在我看来，你最好选择 STE，因为我相信它们与 WPF/MVVM 开发非常吻合。