我有一个关于EF和WCF的架构问题。我们正在使用实体框架(Oracle数据库)和基于WPF的GUI开发一个三层应用程序。GUI通过WCF与服务器通信。
我们的数据模型非常复杂(超过100个表)，有很多关系。我们目前正在使用默认的EF代码生成模板，并且我们在跟踪实体的状态时遇到了很多麻烦。
客户端的用户界面也相当复杂，有时一个超过50个对象的对象图被发送到单个用户界面，实体之间有几层聚合。能够在BLL层中轻松确定哪些对象在客户端上被修改，哪些对象是新创建的，这是一个重要的目标。
在两层之间管理实体和实体状态的最清晰的方法是什么?自我跟踪实体?在这种情况下最常见的陷阱是什么?
那些在真实的生产环境中使用过ste的人能告诉我他们的经验吗?
ste应该可以解决这个问题，但它们不是灵丹妙药。我从来没有在实际项目中使用过它们(我不喜欢它们)，但我花了一些时间玩它们。我发现的主要缺陷有:
- 将你的数据层与你的客户端应用程序耦合-你必须在项目之间共享实体组装(这也意味着它是。net唯一的解决方案，但在你的情况下它不应该是一个问题)
- 大数据传输-你传递50个实体到客户端，客户端改变一个实体，你将传递50个实体。这将需要与STEs进行一些战斗，以避免传递不必要的数据
- 不必要的数据库更新-通常当EF与附加实体一起工作时，它会跟踪属性级别的变化，但对于STEs，它会跟踪实体级别的变化。如果用户在有100个属性的实体中修改单个属性它会生成设置所有属性的更新。这将需要修改模板并添加属性级别更改跟踪来避免这种情况。
- 客户端应用程序应该直接使用STEs(将STEs绑定到UI)来获得大部分的自跟踪能力。否则，你将不得不实现将数据从UI移回自我跟踪实体并修改其状态的代码。
- 他们没有被代理=他们不支持延迟加载(在WCF服务的情况下，这是良好的行为)
我今天描述了在没有ste的情况下解决这个问题的方法。还有一个关于通过web服务进行跟踪的相关问题(查看@Richard的回答和提供的链接)。
我们使用STE开发了一个分层应用程序。一个带有ASP的用户界面层。. NET和ModelViewPresenter，一个业务层，一个WCF服务层和一个实体框架的数据层。
当我第一次读到STE的时候，文档说它们比使用自定义DTO更容易。它们应该是"快速和简单的方法"，只有在真正大的项目中，你才应该使用手写的DTO。
但是我们在使用STE时遇到了很多问题。其中一个主要问题是，如果您的实体来自多个服务调用(例如在主细节视图中)，那么在不同的上下文中，您将在服务器上组合图形并试图保存它们时遇到问题。所以我们的服务器函数仍然需要手动检查哪些数据发生了变化，然后在服务器上重新组合对象图。关于这个话题已经写了很多，但它仍然不容易修复。
我们遇到的另一个问题是，如果没有WCF, STE将无法工作。当实体被序列化时，将激活更改跟踪。我们最初设计了一个架构，其中WCF可以被禁用，服务调用将只是在处理中(这是我们的单元测试的要求，如果没有WCF，它将运行得更快，并且更容易设置)。事实证明，STE并不是正确的选择。
我还注意到，开发人员有时会在查询中包含大量数据，然后将其发送给客户端，而不是真正考虑他们需要哪些数据。
在这个项目之后，我们决定使用自定义DTO与automapper从服务器到客户端，并在一个新项目的数据层中使用POCO模板。
所以既然你已经声明你的项目很大，我会选择为一个目标专门创建的自定义DTO和服务函数，而不是发送大量数据的"Update(Person Person)"函数
希望这对你有帮助