Entity Framework 4.0 is just around the corner and it will bring some long awaited relief. I previously wrote and explained the issues around Persistence Ignorance and POCO as they apply to the Entity Framework. So obviously I’m quite excited about migrating from the interim EFPocoAdapter over to EF 4.0. Let’s take a quick look at the new features in Entity Framework 4.0.

POCO Support

If you are not up to date on POCO, quickly read up on POCO and Persistence Ignorance first. Entity Framework 4.0 has full support for POCO or Plain Old CLR Objects.

If you have a class called Person with name, address and phone number then that’s how it will stay. It will not have EntityKey or some other such properties. It does not need to implement any interface specific to Entity Framework nor does it need to add any special attributes on properties and methods.

You can pass this plain object around much more cleanly and your domain logic is not polluted with any persistence code. This is also useful for Test Driven Development (TDD)  or migrating out of EF to another framework down the line.

Entity Model Designer Improvements

Previously you had to design the database schema in SQL Server and then import that into the Entity Designer. With 4.0 you can build the model first in the Entity Designer and generate your database and classes from there.  Alternately a lot of DDD (Domain Driven Design) folks prefer to hand code their model classes. Since those classes end up being POCO and EF has full support for POCO, it works out quite well for everyone.

T4 templates

Currently the Entity Designer generates classes from models by using EntityClassGenerator which provides little to no control over the generated classes. In 4.0 you will have T4 templates which provide for greater control over the generated classes with richer functionality like adding attributes to properties or having the generated classes implement a custom interface.

T4 templates are used not only to generate classes but also to generate tables if you choose to start off by building the models first. For example, by default the mapping is table-per-type which can be overridden through T4 templates to produce a table-per-hierarchy schema. You can also add prefixes to the generated table names and so on.

Self Tracking Entities and N-Tier applications

Self tracking entities are a very cool feature of the Entity Framework that allow for N-tier applications. Currently when you have entities on which you wish to track changes, the object context does that for you. However, the object context only exists in the current tier and if you decide to pass that object around to other tiers where the context is not present, you cannot track the entities any more. For example, if you pass the Person object to the UI layer which presents it to the user for modification, those modifications are not being tracked because the object context is not available in the UI tier. N-tier support can now handle this scenario quite elegantly.

One way to do this is to generate self-tracking entities as these entities have logic to track changes within. If the UI modifies the Person object’s address, the Person object will now contain information on how it’s been modified because it is self-tracking. When you pass the Person object back to the data tier, the object can easily relay what’s changed and the context can use this to persist the object.

Of course, this means that the object is not POCO any more because it has logic to track changes within itself so there is yet another approach. You can pass the POCO object back to the Entity Framework and attach it to the context which can then do a diff on the object and the original object to determine what’s changed. This requires more processing obviously.

Proxy Tracking

Besides diff’ing the POCO entities or using self-tracking entities for change detection, another approach is provided by the Entity Framework 4.0 which is proxy tracking. It provides the benefits of POCO without the performance implications of doing a diff (to check what’s changed each time the POCO object is re-attached to the context) albiet it cannot be used in an n-tier scenario.

If using proxies to track changes, EF sets up proxy classes to communicate with your POCO classes. These proxy classes inherit from the POCO classes and any property getter/setter calls are still made to the POCO class but through the proxy class. This allows the Entity Framework to stay in sync with entities at all times. You do however need to be a bit careful if you are going to serialize these objects because the resulting output could be a proxy object (though easily remedied by calling something like EFPocoAdapter’s ProxiesToPoco() equivalent in EF 4.0).

Conclusion

This is going to be a big release for EF to bring it in line with the other major ORMs out there. The MVC community right now favors Linq to SQL but hopefully we’ll see more ASP.NET MVC + Entity Framework projects coming out.