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

Question

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

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

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

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

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

Answer 1

STE 应该解决这个问题,但它们不是银弹.我从未在实际项目中使用它们(我不喜欢它们)但我花了一些时间和它们一起玩.我发现的主要缺陷是:

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

我今天描述了在没有STE的情况下解决这个问题的方法.关于跟踪Web服务还有相关问题(查看@ Richard的答案并提供链接).

Answer 2

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

当我第一次阅读关于STE的文档时,他们说使用自定义DTO更容易.它们应该是"快速简便的方式",只有在非常大的项目中你应该使用手写的DTO.

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

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

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

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

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

希望这可以帮助 :)