POCO 与实体框架生成的类？
使用其中一种比另一种有什么优势？我知道 POCO 类更优化，但它们值得大肆杀戮吗？我们应该始终使用 POCO 还是有时您应该更喜欢实体框架类？
What are the advantages of using one over the other ? I know POCO classes are more optimal but are they worth the overkill ? And should we always be using POCO's or is there a time when you should prefer entity framework classes ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
EF 默认类都继承自 EF 基类，而 POCO 则不然（因此得名）。从 EF 基类继承时，更改跟踪背后的逻辑对您隐藏，并且所有逻辑都存储在保存对象引用的上下文中。如果您在连接状态下工作，即您在拥有实体的同时拥有上下文，那么这是首选。这通常是您构建“胖”客户端的情况，因此客户端和数据库是仅有的两层。
另一方面，如果您正在使用 Web 服务/Web 表单，您传递的实体没有上下文并且必须自己跟踪状态 - 那么 POCO 是更好的选择，因为它们具有更改跟踪对象作为它们的属性，可以四处转移，直到您决定将更改应用到上下文并保存。另一项好处是您的客户端不必是 .NET，也不必使用 EF .dll 来反序列化您的对象。
The EF default classes all inherit from EF base class, while POCO don't (hence the name). While inheriting from EF base class, the logic behind change tracking is hidden from you and all of the logic is stored inside the context that's holding references to your objects. This is preferred if you're working in a connected state, ie, you have context at the same time you have entities. This is usually the case where you build 'fat' client, so the client and the database are the only two tiers.
On the other hand, if you're working with web services / web forms, the entities you pass around don't have a context and have to track the state themselves - then the POCO is the better option, since they have change tracking object as their property that can be transferred around until you decide to apply the changes to the context and save. One other benefit would be that your clients don't have to be .NET and don't have to have the EF .dll to deserialize your objects.
我使用 POCO 的原因是关注点分离，即我不希望我的前端必须知道我的后端如何工作。因此，如果我想从 Linq To Sql 更改为 EF 或 N Hibernate，我不必修改我的前端代码。
The reason I use POCO is separation of concerns i.e. I don’t want my front end to have to know how my back end works. So if I want to change from Linq To Sql to EF or N Hibernate I don’t have to modify my front end code.
如果您想要干净的架构、松散的耦合和最高的可测试性，请使用 POCO。
如果您不关心这些东西，那就不要使用它们。
就我个人而言，这些是任何应用程序中最重要的事情（尤其是需要长期维护的应用程序），因此我总是使用 POCO。
考虑到这一点，POCO 要求您实施某种变更跟踪机制，这可能很棘手。但这是一次性设置，值得付出努力。
我在一个自定义 DLL 中有这个逻辑，我在项目之间共享它 - 所以我不必一次又一次地这样做。
有关为什么 POCO 在一般意义上很重要（不是 EF/.NET 特定）的更多信息，请参阅我的答案 这里。
Use POCO's if you want clean architecture, loose coupling and supreme testability.
If you don't care about those things then don't use them.
Personally to me those are the most important things in any application (especially one that is required to be maintained over a long period of time), therefore i always use POCO's.
With that in mind, POCO's require you implement some kind of change tracking mechanism, which can be tricky. But it's a one-time setup thing, and is worth the effort.
I have this logic in a custom DLL which i share amongst projects - so i don't have to keep doing it again and again.
For more info on why POCO's are important in the general sense (not EF/.NET specific), see my answer here.
请参阅以下文章：
http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx< /a>
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
Look at following articles:
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