Entity Framework 1.0 Beta 3

The much anticipated Microsoft ADO.NET Entity Framework (by me at least) has turned out to be a big disappointment.

Entity Framework (EF) is an improvement of the old ADO.NET and supposed to be Microsoft's answer to third-party Object-Relational Mapping (ORM) products, such as Hibernate. However, it totally missed the plot of why people want to have ORM and how these tools are used.

The purpose of ORM is to shield the database details away from the business logic so that the developer does not have to worry about the implementation details of how the data are stored on disk, how the foreign keys relationships are traversed, etc. Developers only need to deal with the domain object model and the domain objects should be modelled as Plain Old .Net Objects (PONO, borrowing from the POJO acronym). This is evident in the tried and true ORM frameworks originated in the Java world: Hibernate, JPA, etc (and to certain extents iBatis SQL Mapper).

The EF way of doing this is to have an Entity Model which can be generated from the database schema. The Entity Model classes inherit from System.Data.Objects.DataClasses.EntityObject, which means that these entity objects are not PONO. So if you want to have a loosely coupled system (between data tier and business tier), then you will need to have a mapping layer between your PONO and these entity objects. This is unnecessary additional work which should have been taken care of by the ORM framework itself.

Another problem with dealing directly with these entity objects is that the developer will have be be aware of the fact that there is a whole new caching layer called entities context which caches the database records in memory in the form of these entity objects. Very often, the developer will have to worry about the synchronisation between the entities context and the actual database (by calling Attach(), Detach() and Load() methods explicitly on the entity model objects) especially when many-to-many relationship associations need to be followed on Delete or Update operations. See my other post on an example of this. Microsoft has also been evangelising the practice of putting these entity objects directly into GUI widgets as their data source. This again creates tight coupling between the data tier and the presentation tier. All these extra data and methods about the entity object life-cycle should be made only visible in the data tier (or DAL, as Microsoft calls it) and nowhere else. That is why PONO should be used throughout the business and presentation tiers, rather than these bloated entity objects. It is disappointing to see that after witnessing all these great ORM examples in the Java world, Microsoft still could not make a decent ORM framework.