POCO VS实体框架生成类？ [英] POCO Vs Entity Framework Generated Classes?

问题描述

使用其中一个优点是什么？我知道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 ?

推荐答案

EF默认类全部继承EF基类，而POCO不（因此名称）。在继承EF基类之后，变更追踪的逻辑隐藏在你的身上，所有的逻辑都存储在持有对象引用的上下文中。如果您处于连接状态，即您具有实体的同时具有上下文，则这是首选。这通常是您构建胖客户端的情况，因此客户端和数据库是唯一的两层。

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.

另一方面，如果您正在工作通过Web服务/ Web表单，您传递的实体没有上下文，并且必须自己跟踪状态 - 那么POCO是更好的选择，因为它们具有更改跟踪对象作为可以转移的属性，直到你决定将更改应用到上下文并保存。另外一个好处就是您的客户不必是.NET，而不必拥有EF .dll来反序列化您的对象。

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 VS实体框架生成类？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！