Persistence Ignorance… Why…?

How do you plan your architecture when you are using entity framework? Do you write a data access layer? Or do you just go ahead and start writing queries on the object context. What happens if you want to use stored procedures? Why stored procedures you ask? well a no. of reasons. Some performance, others just a plain ol’ legacy database with existing stored procedures. But that’s a little out of context at the moment.

You may go ahead and start using your entities as business objects. But there’s a catch. Let me take a step back. Entity Framework entities are just plain ol’ classes with a special interface implementation, which maps the properties of these classes with the database tables and columns. So essentially, there’s a direct mapping of these classes with the database.

Now let’s add a few parameters and make the situation a little more complex. Let’s add a WCF layer to the design.  As far as the WCF Service is concerned, it should not care about who’s accessing it, because it is the Service. It exposes a few contracts and doesn’t care who uses them. It receives the requests and services them.

But to service requests it has to pass data around. Now if the data is of primitive types, it’s fine, but if it is not, if it is of complex serializable type, then we would have proxies running back and forth across the wire.

This proxy types, while being independent of the clients, should also, ideally be, free from any other independencies on the back end. If you are using EF entities, then your data entities are dependant on the database. So if you change your database schema, you would have to re-publish your proxies. Break the data contract and you have to recompile your clients. That, is not a very pleasant thing to do.

I am not sure how I would get around this problem myself. As of now what I can think of is to create my Business Objects / proxy data classes with behavior and everything and map them with the entities. These business objects should not be heavy, should be serializable, should be free from dependencies from either side and should be capable to consume any changes in the database schema. We call them business objects because business should be the only thing it should depend on. If there is a database change, the mapping layer should be able to consume these changes so we don’t have to re-publish our proxies. The data contract should not break.

So then, the question arises, whey use entity framework at all. One of the big benefits that I get out of Entity Framework is that I don’t have to hand code my entities. Well that’s a question I cannot answer at this level. It has to be answered on a case to case basis. Entity Framework gives you some amazing features besides the code gen and if they matter, by all means go for it.

However, Microsoft, I believe has recognized this “problem”, and is working on the solution. .Net Framework 4.0 would come with Persistent Ignorant entities. They introduce the capability to interact with the database without having a dependency on the schema and also without losing any entity framework capabilities. In fact they are introducing a couple of other capabilities like change tracking in POCOs and lazy loading.

Exciting times lie ahead…