3

我想知道是否建议在 WCF 服务中使用 Self Tacking Entities（在实体框架中）？如果是的话，那么你能指导我到一个可以指导如何做到这一点的教程吗？

实际上，我打算使用带有 MEF 和 MVVM 的 Prism 开发一个 WPF 应用程序。我决定使用实体框架。我想要关于这种方法的建议和建议。

任何帮助将不胜感激。

4

2 回答 2

7

我想知道是否建议在 WCF 服务中使用 Self Tacking Entities（在实体框架中）？

这取决于你问谁。如果你问 MS，他们会告诉你是的，因为他们根本没有更好的东西可以提供。STE 是对这个非常古老的MS Connect 建议的回应。问题是 EF 本身对合并两个实体图之间的更改有非常糟糕的支持（您必须完全自己完成），并且在 MS 平台上工作的开发人员（有时包括我）有一些共同的行为：

  • 他们懒得开发自己的解决方案来解决问题，他们希望直接在 MS 提供的 API 中获得一些魔力。
  • 大多数时候，他们没有接受过他们必须使用的技术的培训/熟练/胜任，因为他们不得不经常转向新的技术。
  • 他们知道的唯一 API 是 .NET Framework 的一部分。他们不寻找其他选项，也不比较功能。

前两点是 MS 策略的结果，其中 RAD 成为设计师的同义词（或新的 T4 模板）。

我同意@Richard 对 STE 的看法。我要添加 STE 的另一个缺点——它们在参与者之间移动大型数据集。如果您决定从服务器获取实体图，则更改图中的单个实体并将数据推回它们将再次传输整个图。仅传输更改的实体会导致与 STE 的核心逻辑发生冲突。我还担心他们会完全跟踪每个实体级别而不是每个属性级别的更改。如果修改具有大型二进制或字符串数​​据的实体，可能会导致在服务和数据库之间以及服务和客户端之间传输过多不需要的数据。

无论如何，对于具有低数据流量和小型实体的简单应用程序，它们可以做得很好，并允许您快速构建应用程序，但无需严格分离关注点。您将从服务中获取实体并将它们直接绑定到 WPF UI，它们将能够为您跟踪更改。稍后您会将实体推送回服务，它们将能够持久保存更改。您的客户端和服务将紧密耦合，但在某些情况下它可能已经足够好了。

于 2011-07-11T08:37:26.617 回答
4

我一般会避免自我跟踪实体 - 我在这里写了博客。

创建您自己的 DTO 并使用它们来管理数据传输 - 然后在服务中构建您的 POCO 对象并将它们与实体框架一起使用以实现持久性

如果您想要自我跟踪，那么这里有一种更清洁的方法

于 2011-07-10T16:53:52.397 回答