Persistence Ignorance in Entity Framework 4.0

The intent of this post is to address below questions
a. clarify what exactly is "Persistence Ignorance"
b. what is problem with default Entity Framework infrastructure
c. How we addressed it

Its is quite common to serialize and de-serialize the objects in most of the scenarios.
so all i want to send to the other side is the properties and the key value pair for that properties.

But if you look at the default entity classes generated by Entity frame work.
It not only have details about the properties of the class . but also exposing the additional key value pair information like whats is the class from which the current object is created, what is the namespace, what are the properties tracking the changes and what are the methods called by those properties.

For instance , look at the below snapshot of the class definition in a default class generated by Entity Framework.
As we are aware of the fact that all the entities will be generated to a single file by default, i am just highlighting one single entity for better understanding.
Now, you can clearly see that in class definition there is no proper separation of concerns in entities generated by Entity Framework by Default.
Thus we lack Persistence Ignorance in default approach.
But Entity Framework came up with a great flexibility by allowing the POCO integration with EF 4.0.

Lets see what changes were brought by this.

When you choose the POCO Template two T4 template files are added to your project. In this case one is called “POCOEntities.Context.tt” and the other is called “POCOEntities.tt”. T4 stands for "Text Template Transformation Toolkit", and is a template engine that ships with Visual Studio. The Entity Framework POCO Template leverages T4 to allow you to customize code generation.

The “POCOEntities.tt” file is responsible for generating a file for each EntityType and ComplexType in the “EntityMVCDB.edmx” model.

POCEntities.cs an additional class file will be generated with POCOEntities.tt. This class will be taking care of run time binding of different Foreign keys. Means, if Class A has a property of type Class B, both the classes will be generated individually with simple property names. But the association will be achieved in run time using this single class file.

The second template (“POCOEntities.Context.tt”) produces a strongly typed ObjectContext for the “EntityMVCDB.edmx” model. You use this strongly typed ObjectContext to interact with your database.

By splitting the template into two, one part that generates the Entity Types and Complex Types and one that generates a strongly typed context, it makes it possible not only to have Entities and ComplexType that are persistence ignorant but further to put those classes in an assembly / project (DAL) that has no persistence aware code in it at all. 

As a final result the entity was generated in second template with no persistence information and everything apart from required properties are encapsulated. Now, when my object got de-serialized on other side no additional information will be carried to the client.

Have a look at the snapshots of Entity generated by POCO:

Is it helpful for you? Kindly let me know your comments / Questions.

No comments:

Post a Comment