wcf - 是否建议将 self 跟踪实体与 WCF 服务一起使用？

Question

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

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

任何帮助将不胜感激。

Answer 1

I want to know if using Self Tacking Entities (in Entity Framework) is recommended with WCF services?

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

他们懒得开发自己的解决方案来解决问题，他们希望直接在 MS 提供的 API 中获得一些魔力。

大多数时候，他们没有在必须使用的技术方面接受过培训/熟练/胜任，因为他们不得不经常转向新的技术。

他们知道的唯一 API 是 .NET Framework 的一部分。他们不寻找其他选项，也不比较功能。

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

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

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