Which are the differences and similarities of POCOs, Trackable Entities and EntityObjects_问答_开发者

Although I have some .net o/rm notions, I'm confused about three terms in EF4 parlance: Trackable entities, EntityObjects and POCOs.

1) Could you state their differences?

2) Could you s开发者_如何学Gotate their similarities?

3) When should them be used?

4) When should them not be used?

5) Is it possible to mix combinations of them in a project?, (i.e. suppose that you have already a lot of code written to manage EntityObjects, is it easy to implement POCOs?)

Thanks

Let me try:

EntityObject is a Entity Framework base class; by default, when you create a new Entity Framework model, this is the class all the classes representing your tables will inherit from. It contains all the logic and code needed to do all the EF magic.
POCO are Plain Old CLR Objects - just plain objects you have, no dependency on EF, just plain classes
Trackable Entities are basically "POCOs on stereoids" - POCO classes that have additional functionality to track their state (unmodified, modified etc.) so they can be sent across several tiers (and back) and be used almost like regular EntityObjects in the end

The easiest to use are EntityObject descendant - you just use them, everything great and works. However: doing this tightly binds you to Entity Framework, and this can be an architectural problem.

Using only POCOs is the "purest" - you're dealing with plain classes only, and EF does all its magic "behind the scenes" - but it takes a bit of additional code and effort to get this to work fine.

Trackable (or self-tracking) entities seems like a great compromise between the two, but I haven't had enough exposure to all the mechanics and inner workings yet to be able to give any reasonable recommendation on those.

So I would recommend:

start with regular Entity Framework data model, the visual designer and all, and use EntityObject descendants and just get into using EF and how it works
if you feel the need, explore POCO or STE (self-tracking entities) in more detail when you have a basic understanding of EF

Here is some additional info on the differences between EntityObject, Trackable Entities, and POCO's.

1) EntityObject is an entity base class used for legacy EF apps. You should avoid it at all costs, as it tightly couples your entities to EF, which is a bad thing. And with EF POCO support, it is completely unnecessary, because EF now provides many of the same features without the base class.

2) POCO classes are ignorant of persistence concerns. They do not need to derive from a base class or have special attributes. They provide independence from the data access API, such as EF.

3) Trackable Entities are a type of POCO classes that have one or two additional properties for setting the entity state: Unchanged, Added, Modified, Deleted. While these properties do pertain to persistence in general, they do not couple entities to any particular persistence framework, including Trackable Entities. Rather, they enable some persistence framework on the back end to interpret and apply those properties, which are extremely lightweight and framework independent.

The main advantage of Trackable Entities, which is a replacement for Microsoft's now defunct Self-Tracking Entities, is that it allows you to persist changes to a graph of related objects in one transaction with a single round trip to a WCF or Web API service. For example, if you have an Order with multiple details, some of which are added, modified or deleted, the Order and details can be sent in one shot, and all the updates take place atomically.

Trackable Entities has other benefits as well, especially in terms of productivity. It is implemented as a set of NuGet packages and Visual Studio extensions (2012, 2013) that let you put together an N-Tier solution in a fraction of the time.

Cheers, Tony