EDMX模型的不同代码生成项之间有哪些本质区别？
我正在尝试加强实体框架，这样我就不会觉得自己处于黑暗时代。我尝试（到目前为止尚未成功）从生成的代码中直观地了解可用代码生成项之间的本质区别。
POCO 似乎将实体数据结构与将它们移入/移出数据存储的对象隔离开来。
我不确定什么是“自我跟踪实体”。我猜测跟踪部分是指实现所谓的“工作单元”模式，但我并不肯定。更令人头疼的是，我想我想知道“自我跟踪而不是什么？”。
I'm trying to ramp up on the entity framework so I don't feel like I'm in the dark ages. I tried (and have thus far failed) to intuit from generated code what the essential differences between the available code generation items.
It seems POCO isolates the entity data structures from the ojbect that moves them in/out of a datastore.
I'm not sure what a "Self-Tracking Entity" is. I'm guessing the tracking part refers realizing the so called "unit of work" pattern, but I'm not posative. And more head scratchingly, I guess I'm wondering "self tracking as opposed to what?".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
POCO 生成器
POCO 代表普通旧 C#（或 CLR）对象。 POCO 独立于 EF。它们只是遵循一些规则的类，但如果需要，您可以从自己的类型继承它们。它们也不包含任何持久性相关数据。
目前这种类型最受欢迎，因为 POCO 和轻量级是当前架构方法的趋势。在某些情况下，使用 POCO 会更复杂，但这是持久性无知架构的代价。
EntityObject Generator
此生成器生成与 EDMX 的默认代码生成方法相同类型的实体。这些实体派生自 EntityObject 类，这使得它们完全依赖于实体框架（我称它们为重实体）。这种依赖性为它们提供了一些额外的功能或简化，但这使得它们在分离场景中更难使用，并且它们的使用导致上层与实体框架紧密耦合的架构，或者在实现更好的分离时导致额外的复杂性。
这种类型的实体是第一个 EF 版本中唯一支持的类型。甚至每个人都使用 POCO 来实现更好的分离，这种类型是 EF 原生的，并且可能提供大多数功能。
该生成器还使您的实体可序列化（使用 DataContractSerializer）。
自跟踪实体 (STE) 生成器
这是非常特殊类型的 POCO 生成器。使用 EF 时，我们有两种不同的场景。在附加场景中，EF 跟踪对实体所做的更改；在分离场景中，您在 EF 范围之外进行了更改，一旦将实体附加到 EF，您必须告诉它您做了哪些更改。典型的分离场景是 Web 服务，您将实体传递给客户端，一旦客户端将它们传回，您必须以某种方式同步更改，以便 EF 知道它必须生成哪些 SQL 命令。 STE 适用于这些独立场景。它们是变更集模式的实现=它们跟踪其当前状态以及自跟踪开始以来所做的更改（如旧数据集所做的那样）。
这是一个理论。在现实世界中，STE 有一些很大的缺点，但很适合仅适用于非常特定的场景。
编辑：
还有一个生成器与 Entity Framework 4.1 一起安装。
DbContext Generator
该生成器导致与 POCO 生成器相同的实体。唯一的区别是使用的 API。 POCO 生成器使用 ObjectContext API，而 DbContext 生成器使用带有 DbContext API 的 POCO（仅在 EF 4.1 和 2011 年 6 月 CTP 中可用）。这些 API 之间的区别在于 选择。
POCO Generator
POCO stands for Plain Old C# (or CLR) Object. POCOs are independent on EF. They are just classes following some rules but you can inherit them from your own type if you want. They also don't include any persistence dependent data.
Currently this type is most popular because it is trend of current architecture approaches to have everything POCO and lightweight. In some situations using POCOs is more complex but that is a price for persistence ignorant architecture.
EntityObject Generator
This generator produces the same type of entities as the default code generation method for EDMX. These entities derive from EntityObject class which makes them fully dependent on Entity framework (I call them heavy entities). This dependency offers them some additional features or simplifications but it makes them harder to use in detached scenarios and their usage leads either to architecture with tight coupling of upper layers to Entity framework or to additional complexities when achieving better separation.
This type of entities was the only type supported in the first EF version. Even everybody is using POCOs to achive better separation this type is native for EF and probably offers most features.
This generator also makes your entities serializable (with DataContractSerializer).
Self tracking entities (STE) Generator
This is very special type of POCO generator. When working with EF we differ two scenarios. Attached scenarion where EF tracks changes made to entity and detached scenario where you did changes outside of EF scope and once you attached entity to EF you must tell it what changes you did. Typical detached scenarios are web services where you pass entities to the client and once the client passes them back you must somehow synchronize changes so that EF knows what SQL commands it must generate. STEs are for these detached scenarios. They are implementation of change set pattern = they track their current state as well as changes made since self tracking started (as old DataSet did).
This is a theory. In the real world STEs have some big disadvantages and are suitable only for very specific scenarios.
Edit:
There is one more generator which is installed together with Entity Framework 4.1.
DbContext Generator
This generator leads to the same entities as POCO generator. The only difference is used API. POCO generator uses ObjectContext API whereas DbContext generator uses POCOs with DbContext API (only available in EF 4.1 and June 2011 CTP). The difference between these APIs is matter of choice.