Entity Framework FAQ: Architecture and Patterns

Does the Entity Framework support entity objects being responsible to save changes themselves (rather than a central Save method on object context)?

This is something we considered but in the end rejected in favor of the broader "unit of work" pattern where you can make changes to a series of related objects and then save them all at once. This is particularly useful when you are modifying relationships between entities or making changes to multiple entities that you want in a single transaction.  You could do manual transaction management either way, but the default transactions that the Entity Framework supplies cover a large number of scenarios.  You could, with some work, maintain a reference from your entities back to the object context they go with and add a Save method to the entities, but it would still save all the outstanding changes on the context, so that would probably be confusing and error prone.  So this is an area that we don't directly support, but arguments can be made for either approach. 

 

Does the Entity Framework have support for "Persistence Ignorance"? 

What is Persistence Ignorance? 

Definitions:

Persistence ignorance is the general term for how much knowledge the objects must have of the persistence layer.  In this case we talk primarily about "complete persistence ignorance," which is a step further than POCO in the sense that you can create an assembly of domain objects where that assembly has no reference to a persistence stack, and then just by adding a small amount of code/configuration on the outside you can persist those objects.

What is POCO?

POCO is basically the idea of having plain CLR objects that do not have special requirements in order to work with a persistence stack like the EF.  In practice this primarily means not requiring that the objects inherit from a particular base class and not requiring that they implement a particular interface.  Many systems might be said to support POCO but still require something like attributes on the classes or other things to help convey information to the persistence stack.  The point, though, is that the domain objects don't have to change substantively to support persistence, so they are cleaner for remoting to other tiers, it's easier to switch to another persistence stack at a later date, etc.

What is IPOCO?

IPOCO is a subset of POCO which says that the objects don't have to inherit from a particular base class but they either gain some benefit from implementing certain interfaces or may even be required to implement those interfaces.

Prescriptive classes or generated classes represent the other end of the spectrum.  In these scenarios, the classes typically inherit from a particular base class that works directly with the persistence layer.  In many cases the classes are auto-generated from a model of some kind and users can extend them by using partial classes or the like.  Prescriptive classes have the disadvantage of being more tied to the persistence layer, but they tend to have advantages when it comes to performance as well as providing a broader set of services that application developers would otherwise have to write themselves.

The EF started out as a framework that only supported prescriptive classes.  Based on customer feedback we decided that it would be very important to support a greater degree of persistence ignorance for some scenarios, but we also believe that the prescriptive classes are great for other scenarios.

EF 4 supports full persistence ignorance (including POCO). This means that you can use "plain-old" CLR objects (POCO), such as existing domain objects, with your data model. These POCO data classes, which are mapped to entities that are defined in a data model, can be in an assembly which has no references to any Entity Framework assembly, and they support most of the same query, insert, update, and delete behaviors as entity types that are generated by the Entity Data Model tools. For more information, see Working with POCO Entities

3.5 SP1 supports prescriptive classes and IPOCO.  That is, you can have classes that do not inherit from an EF base class, but they must implement certain interfaces and they must have specific attributes in order to work with the EF.  For more information, see Implementing Custom Data Class Interfaces (Entity Framework).

Should I use my EF entities as my business/domain objects or should I have separate classes for my persistence layer and my business layer?

This is a question for which there isn't one clear answer.  On the one hand, the EF (especially now that it supports persistence ignorance) is designed to make this possible in a way that it wasn't when not using O/RM technology because the mapping layer of the EF gives you an abstraction to help isolate your entities from the database.  On the other hand, some would argue that while this separation is helpful it may not be enough to fully isolate your entities or that you at least might wnat to introduce data transfer objects (or DTOs) if you decide to expose a web service rather than flowing your entities all the way across to a different tier.

For more information see this discussion on stack overflow.