似乎POCO将实体数据结构与将其移入/移出数据存储区的ojbect进行隔离.
我不知道“自我跟踪实体”是什么.我猜到跟踪部分是指实现所谓的“工作单位”模式,但我不是定位的.还有更多的头痛,我想我想知道“自我跟踪而不是什么？”.
解决方法
POCO代表普通老C#(或CLR)对象. POCO独立于EF.他们只是遵循一些规则的类,但是如果需要,您可以继承自己的类型.它们也不包括任何依赖于持久性的数据.
目前这种类型是最受欢迎的,因为它是目前架构方法的趋势,拥有一切POCO和轻量级.在某些情况下,使用POCO更复杂,但这是持久性无知架构的代价.
EntityObject Generator
该生成器生成与EDMX的默认代码生成方法相同类型的实体.这些实体从EntityObject类派生,这使得它们完全依赖于实体框架(我称之为重实体).这种依赖性为他们提供了一些额外的功能或简化,但是它们使得它们更难在分离的场景中使用,并且它们的使用导致了上层与实体框架的紧密耦合的架构,或者在实现更好的分离时的额外的复杂性.
这种类型的实体是第一个EF版本支持的唯一类型.即使每个人都使用POCO来获得更好的分离,这种类型是EF的本地类型,并且可能提供大多数功能.
该生成器还使您的实体可序列化(使用DataContractSerializer).
自动跟踪实体(STE)发生器
这是非常特殊的POCO发生器.在使用EF时,我们会区分两种情况. EF附加的情景跟踪您在EF范围之外进行更改的实体和分离场景所做的更改,一旦您将实体附加到EF,您必须告诉您所做的更改.典型的脱机方案是将实体传递给客户端的Web服务,一旦客户端将其传递回来,您必须以某种方式同步更改,以便EF知道必须生成哪些sql命令. STEs are for these detached scenarios.他们是变更集模式的实现=他们跟踪他们当前的状态以及自动跟踪开始以来的变化(像旧DataSet那样).
这是一个理论.在现实世界中,STE有一些big disadvantages,只适用于非常具体的场景.
编辑：
还有一个与Entity Framework 4.1一起安装的生成器.
DbContext生成器
该发电机产生与POCO发生器相同的实体.唯一的区别是使用API. POCO生成器使用ObjectContext API,而DbContext生成器使用具有DbContext API的POCO(仅在EF 4.1和2011年6月的CTP中可用).这些API之间的区别是matter of choice.
