EF +具有复杂对象图的三层应用程序中的 WCF。使用哪种模式？
我有一个关于 EF 和 WCF 的架构问题。 我们正在使用实体框架（带有 Oracle 数据库）和基于 WPF 的 GUI 开发一个三层应用程序。 GUI通过WCF与服务器通信。
我们的数据模型非常复杂（一百多个表），有很多关系。我们当前使用默认的 EF 代码生成模板，并且在跟踪实体的状态时遇到很多麻烦。
客户端上的用户界面也相当复杂，有时将包含 50 多个对象的对象图发送到单个用户界面，实体之间有多层聚合。一个重要的目标是能够在BLL层轻松决定哪些对象在客户端被修改，哪些对象被新创建。
管理两层之间的实体和实体状态的最清晰方法是什么？自跟踪实体？这种情况下最常见的陷阱是什么？
有在实际生产环境中使用过STE的人能否介绍一下他们的经验？
I have an architectural question about EF and WCF.
We are developing a three-tier application using Entity Framework (with an Oracle database), and a GUI based on WPF. The GUI communicates with the server through WCF.
Our data model is quite complex (more than a hundred tables), with lots of relations. We are currently using the default EF code generation template, and we are having a lot of trouble with tracking the state of our entities.
The user interfaces on the client are also fairly complex, sometimes an object graph with more than 50 objects are sent down to a single user interface, with several layers of aggregation between the entities. It is an important goal to be able to easily decide in the BLL layer, which of the objects have been modified on the client, and which objects have been newly created.
What would be the clearest approach to manage entities and entity states between the two layers? Self tracking entities? What are the most common pitfalls in this scenario?
Could those who have used STEs in a real production environment tell their experiences?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
STE 应该可以解决这种情况，但是它们不是灵丹妙药。我从未在实际项目中使用过它们（我不喜欢它们< /a>）但我花了一些时间和他们一起玩。我发现的主要陷阱是：
我今天描述了 无需 STE 即可解决此问题。还有相关问题通过网络服务进行跟踪（检查@Richard的答案和提供的链接）。
STEs are supposed to solve this scenario but they are not silver bullet. I have never used them in real project (I don't like them) but I spent some time playing with them. The main pitfalls I found are:
I described today the way to solve this without STEs. There is also related question about tracking over web services (check @Richard's answer and provided links).
我们使用 STE 开发了分层应用程序。用户界面层采用 ASP.NET 和 ModelViewPresenter，业务层、WCF 服务层和数据层采用实体框架。
当我第一次阅读有关 STE 的文档时，文档说它们比使用自定义 DTO 更容易。它们应该是“快速而简单的方法”，并且只有在真正的大型项目中才应该使用手写的 DTO。
但我们在使用 STE 时遇到了很多问题。主要问题之一是，如果您的实体来自多个服务调用（例如在主详细信息视图中），并且来自不同的上下文，那么在服务器上构建图形并尝试保存它们时，您将遇到问题。所以我们的服务器函数仍然需要手动检查哪些数据发生了变化，然后在服务器上重构对象图。关于这个主题已经有很多文章了，但解决起来仍然不容易。
我们遇到的另一个问题是，如果没有 WCF，STE 将无法工作。当实体被序列化时，更改跟踪被激活。我们最初设计了一种架构，其中 WCF 可以被禁用，而服务调用只会在进行中（这是我们单元测试的要求，如果没有 WCF，单元测试会运行得更快，并且更容易设置）。事实证明，STE 并不是正确的选择。
我还注意到，开发人员有时会在查询中包含大量数据，然后将其发送给客户端，而不是真正考虑他们需要哪些数据。
在这个项目之后，我们决定使用自定义 DTO 和从服务器到客户端的自动映射器，并在新项目的数据层中使用 POCO 模板。
因此，既然您已经声明您的项目很大，我会选择专门为一个目标创建的自定义 DTO 和服务功能，而不是发送大量数据的“更新（人员）”功能
希望这会有所帮助:)
We have developed a layered application with STE's. A user interface layer with ASP.NET and ModelViewPresenter, a business layer, a WCF service layer and the data layer with Entity Framework.
When I first read about STE's the documentation said that they are easier then using custom DTO's. They should be the 'quick and easy way' and that only on really big projects you should use hand written DTO's.
But we've run in a lot of problems using STE's. One of the main problems is that if your entities come from multiple service calls (for example in a master detail view) and so from different contexts you will run into problems when composing the graphs on the server and trying to save them. So our server function still have to check manually which data has changed and then recompose the object graph on the server. A lot has been written about this topic but it's still not easy to fix.
Another problem we ran into was that the STE's wouldn't work without WCF. The change tracking is activated when the entities are serialized. We've originally designed an architecture where WCF could be disabled and the service calls would just be in process (this was a requirement for our unit tests, which would run a lot faster without wcf and be easier to setup). It turned out that STE's are not the right choice for this.
I've also noticed that developers sometimes included a lot of data in their query and just send it to the client instead of really thinking about which data they needed.
After this project we've decided to use custom DTO's with automapper from server to client and use the POCO template in our data layer in a new project.
So since you already state that your project is big I would opt for custom DTO's and service functions that are a specifically created for one goal instead of 'Update(Person person)' functions that send a lot of data
Hope this helps :)