具有复杂对象图的三层应用程序中的EF + WCF。使用哪种模式？

Question

我有一个关于EF和WCF的架构问题。 我们正在使用Entity Framework（带有Oracle数据库）和基于WPF的GUI开发三层应用程序。 GUI通过WCF与服务器通信。

我们的数据模型非常复杂（超过一百个表），有很多关系。我们目前正在使用默认的EF代码生成模板，我们在跟踪实体状态方面遇到了很多麻烦。

客户端上的用户界面也相当复杂，有时将具有50个以上对象的对象图发送到单个用户界面，实体之间有多层聚合。能够轻松决定BLL层，在客户端上修改了哪些对象，以及新创建了哪些对象，这是一个重要的目标。

在两个层之间管理实体和实体状态最明智的方法是什么？自我跟踪实体？这种情况下最常见的陷阱是什么？

那些在真实生产环境中使用STE的人能说出他们的经历吗？

Answer 1

STE是supposed to solve this scenario但他们不是银弹。我从未在真实项目中使用它们（I don't like them），但我花了一些时间和它们一起玩。我发现的主要缺陷是：

• 将数据层与客户端应用程序耦合 - 您必须在项目之间共享实体程序集（这也意味着它只是.NET解决方案，但在您的情况下不应该是问题）
• 大数据传输 - 您将50个实体传递给客户端，客户端更改单个实体，您将传回50个实体。为了避免传递不必要的数据，需要与STE进行一些斗争
• 对数据库进行不必要的更新 - 通常当EF与附加实体一起工作时，它会跟踪属性级别的更改，但是使用STE会跟踪实体级别的更改。因此，如果用户在具有100个属性的实体中修改单个属性，它将生成更新并设置所有属性。它需要修改模板并添加属性级别更改跟踪以避免这种情况。
• 客户端应用程序应直接使用STE（将STE绑定到UI）以获得其大部分自我跟踪能力。否则，您将不得不实现将数据从UI移回自我跟踪实体并修改其状态的代码。
• 他们没有被代理=他们不支持延迟加载（在WCF服务的情况下它是良好的行为）

我今天描述了solve this without STEs的方式。关于网络服务的跟踪也有related question（查看@ Richard的答案并提供链接）。

Answer 2

我们开发了STE的分层应用程序。具有ASP.NET和ModelViewPresenter的用户界面层，业务层，WCF服务层和具有实体框架的数据层。

当我第一次阅读关于STE的文档时，文档说它们比使用自定义DTO更容易。它们应该是“快速简便的方式”，只有在非常大的项目上才能使用手写的DTO。

但是我们使用STE's遇到了很多问题。其中一个主要问题是，如果您的实体来自多个服务调用（例如在主详细信息视图中），并且来自不同的上下文，则在编写服务器上的图形并尝试保存它们时会遇到问题。因此，我们的服务器功能仍然需要手动检查哪些数据已更改，然后重新组合服务器上的对象图。关于这个主题已经写了很多，但它仍然不容易修复。

我们遇到的另一个问题是如果没有WCF，STE将无法运行。在序列化实体时激活更改跟踪。我们最初设计了一个体系结构，其中WCF可以被禁用，服务调用就在进行中（这是我们的单元测试的要求，如果没有wcf并且更容易设置，它将运行得更快）。事实证明，STE不是这个的正确选择。

我还注意到，开发人员有时会在查询中包含大量数据，只是将其发送给客户端，而不是真正考虑他们需要哪些数据。

在这个项目之后，我们决定使用自定义DTO和从服务器到客户端的automapper，并在新项目的数据层中使用POCO模板。

因此，既然您已经声明您的项目很大，我会选择专门为一个目标创建的自定义DTO和服务功能，而不是发送大量数据的“更新（人员）”功能

希望这会有所帮助：）