Question

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 state 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

Answer 1

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