EDMX模型的不同代码生成项目之间的重要区别是什么? [英] What are essential differences betweeen the different code generation items for EDMX model?

查看:96
本文介绍了EDMX模型的不同代码生成项目之间的重要区别是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正试图加速实体框架,所以我不觉得我在黑暗的时代。我试图(并且迄今为止失败)从生成的代码直觉什么是可用代码生成项目的基本差异。



似乎POCO将实体数据结构与ojbect将它们移入/移出数据存储区。



我不知道自我跟踪实体是什么。我猜到跟踪部分是指实现所谓的工作单位模式,但我不是定位的。还有更多的头痛,我想我想知道自我跟踪而不是什么?。



解决方案

POCO生成器



POCO表示Plain Old C#(或CLR)对象。 POCO独立于EF。他们只是遵循一些规则的类,但是如果需要,您可以继承自己的类型。它们也不包括任何依赖于持久性的数据。



目前这种类型是最受欢迎的,因为它是当前架构方法的一个趋势,拥有一切POCO和轻量级。在某些情况下,使用POCO更复杂,但这是持久性无知架构的代价。



EntityObject Generator



该生成器生成与EDMX的默认代码生成方法相同类型的实体。这些实体从EntityObject类派生,这使得它们完全依赖于实体框架(我称之为重实体)。这种依赖关系为他们提供了一些额外的功能或简化,但它使得它们更难在分离的场景中使用,并且它们的使用导致了上层与实体框架紧密耦合的架构,或者在实现更好的分离时会增加复杂性。



这种类型的实体是第一个EF版本中支持的唯一类型。即使每个人都使用POCO来获得更好的分离,这种类型是EF的本机,并且可能提供大多数功能。



此生成器还使您的实体可序列化(使用DataContractSerializer)。 p>

自我跟踪实体(STE)生成器



这是非常特殊的POCO生成器。在使用EF时,我们会区分两种情况。 EF附加的情景跟踪您在EF范围之外进行更改的实体和分离场景所做的更改,一旦您将实体附加到EF,您必须告诉您所做的更改。典型的脱机方案是将实体传递给客户端的Web服务,一旦客户端将其传递回来,您必须以某种方式同步更改,以便EF知道必须生成哪些SQL命令。 STE用于这些分离的场景。他们是实现变化集模式=他们跟踪他们当前的状态以及自我跟踪开始以来的变化(像旧DataSet一样)。



这是一个理论。在现实世界中,STE有一些大的缺点,并且适合



编辑:



还有一个生成器它与Entity Framework 4.1一起安装。



DbContext Generator



此生成器导致与POCO相同的实体发电机。唯一的区别是使用API​​。 POCO生成器使用ObjectContext API,而DbContext生成器使用具有DbContext API的POCO(仅在EF 4.1和2011年6月的CTP中可用)。这些API之间的区别是选择


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 bwtween 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?".

解决方案

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.

这篇关于EDMX模型的不同代码生成项目之间的重要区别是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆