实体框架 + POCO垮台？
我听说 POCO 与实体框架有缺点，但我不能 100% 确定它们是什么。我听说变更跟踪存在问题。主要缺点是什么？解决方法是什么？我正在考虑在即将到来的项目中使用 POCO 实体，并希望做好充分准备。
谢谢！
I have heard that there are downsides to POCO with Entity Framework, but I am not 100% sure what they are. I heard that there are issues with change tracking. What are the major downsides and what are the workarounds? I am looking into using POCO Entities in an upcoming project and want to be fully prepared.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
失败取决于您要编写的应用程序的类型。从架构角度来看，POCO 非常出色，因为它们不会引入对实体框架的依赖。变更跟踪的问题可以分为两个单独的部分：
分离的实体不仅仅是 POCO 的问题。这是 EF 中的一个全局问题，也许是整个 ORM 概念中的一个全局问题（但其他 API 可能有更好的工具来处理这个问题）。关键是 ORM 负责持久化对实体所做的更改。为此，它提供了一些更改跟踪机制，但这些更改跟踪机制仅在 ORM 知道实体时才起作用。一旦您分离实体（在 EF 调用
Detach或处置ObjectContext或创建实体而不从数据库加载实体的情况下 - 在 Web 应用程序和 Web 服务中常见），EF 不会了解更改，一旦您想要保存实体，您必须告诉 EF 发生了什么更改。这是在以下情况下很容易做到单个实体但它是对于整个对象来说是相当大的挑战图形。 STE可以部分解决这个问题，但是<一href="https://stackoverflow.com/questions/3814706/self-tracking-entities-vs-poco-entities/3815968#3815968">我不认为 STE 是解决该问题的良好解决方案 -它们仅在某些情况下有用。性能问题也与变更跟踪有关。有多个报告表明，如果 EF 要跟踪实体中的更改，则需要很长时间才能初始化更改跟踪（当 实体从数据库加载或当它是附加到上下文）。仅当您计划使用大型数据集时，此问题才很重要。
仍然有很多使用 POCO 的成功项目，并且大多数项目可能从未遇到任何这些问题。
Downfalls depends on type of application you are going to write. POCOs are great from architecture perspective because they do not introduce dependency on Entity framework. The problems with change tracking can be divided into two separate blocks:
Detached entities are not only problem of POCOs. It is a global problem in EF and perhaps in the whole ORM concept (but other APIs have probably better tools for dealing with this problem). The point is that ORM is responsible for persisting changes made to entities. To do this it offers some change tracking mechanisms but these change tracking mechanisms work only if ORM knows the entity. Once you detach an entity (in case of EF call
Detachor disposeObjectContextor create entity without loading it from database - common in web applications and web services) EF doesn't know about changes and once you want to save the entity you must tell EF what has changed. This is easy to do in case of single entity but it is pretty big challenge in case of whole object graph. This can be partially solved by STEs but I don't think that STEs are good solution for the problem - they are useful only in some scenarios.Performance problems are related to change tracking as well. There are several reports showing that if EF wants to track changes in entities it requires very long time to initialize change tracking (when entity is loaded from database or when it is attached to the context). This problem is important only if you plan to work with large data sets.
There is still a lot of successful projects using POCOs and most of the projects probably never meet any of these issues.