POCO与实体框架生成的类？

Question

使用其中一种的优点是什么？我知道POCO课程更优化，但它们值得过度杀伤？我们是否应该一直使用POCO？或者是否有一段时间您应该更喜欢实体框架类？

Answer 1

EF默认类都从EF基类继承，而POCO不（因此名称）。从EF基类继承而来，变更追踪背后的逻辑对你来说是隐藏的，所有的逻辑都存储在持有对象引用的上下文中。如果你在连接状态下工作，那么这是首选，也就是说，你在有实体的同时有上下文。这通常是您建立“胖”客户端的情况，所以客户端和数据库是唯一的两个层。另一方面，如果您使用的是Web服务/ Web表单，那么您传递的实体没有上下文并且必须自己跟踪状态 - 那么POCO是更好的选择，因为它们将跟踪对象的属性更改为可以转移的属性，直到您决定将更改应用于上下文并保存为止。另一个好处是你的客户不必是.NET，也不需要EF.DLL反序列化你的对象。

Answer 2

我使用POCO的原因是关注点的分离，即我不希望我的前端必须知道我的后端是如何工作的。所以如果我想从Linq To Sql更改为EF或N休眠，我不必修改我的前端代码。

Answer 3

如果您需要干净的架构，松耦合和最高的可测性，请使用POCO。

如果你不关心这些东西，那就不要使用它们。

对我个人而言，这些是任何应用程序中最重要的事情（尤其是需要长时间维护的应用程序），因此我总是使用POCO。

有鉴于此，POCO要求您实施某种更改跟踪机制，这可能会非常棘手。但这是一次性设置，值得努力。

我在一个自定义的DLL中有这个逻辑，我在项目之间共享 - 所以我不必一直这样做。

有关POCO为什么在一般意义上很重要的更多信息（而不是EF/.NET特定），请参阅我的回答here。

Answer 4

请看下面的文章：

http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

http://blogs.msdn.com/b/adonet/archive/2009/05/28/poco-in-the-entity-framework-part-2-complex-types-deferred-loading-and-explicit-loading.aspx

http://blogs.msdn.com/b/adonet/archive/2009/06/10/poco-in-the-entity-framework-part-3-change-tracking-with-poco.aspx