Giorgio Galante

This post is about the 3rd reason I would not recommend using Microsoft’s Entity Framework 4: We Can’t wait for Microsoft to build the features we want, when there are other inexpensive or free solutions already out there.

Simply put, there are better, more mature, products out there than EF4.  If you’re building a simple desktop To-Do List application with SQL CE – then by all means, use EF (as long as you don’t want to use Identity keys/server-generated values, because that’s not supported.) It’s free, it comes with .NET, etc.  But if you’re building a real enterprise application that doesn’t fit into Microsoft’s neat Entity Framework feature-set, don’t even risk it.

One of my client’s developers has been looking at replacing our initial ORM selection (LLBLGen Pro) with Entity Framework 4.  We are still at a very early stage in development, with little time/money invested in the ORM layer – switching will not be an expensive proposition.  We’re using the model-first approach (i.e. start off designing the conceptual model and then it will generate your database schema.)  We seem to be doing a lot of T4 Self-Tracking entities template modifications, of which I am not a fan of.  Particularly because once we make a change to a vendor-provided template, we are stuck supporting it.   The whole point for using an ORM is that it should be a highly configurable black-box.  You should only have to customize the black box when dealing with edge-case scenarios.  This doesn’t seem to be the case - the developer charged with the evaluation / migration to EF is a smart & seasoned developer – I don’t believe he’s just diving into template customization for ‘fun’.  During this dive into EF4, we also discovered that the Entity Framework’s Model-First (using Self-Tracking Entities?) approach does not support the SQL Server timestamp type.  Maybe it’s a bug, maybe it’s a feature on their to-do-list.  Either way – it’s another sign that Entity Framework 4 is not mature enough. 

By default, EF4 has Lazy Loading turned on for new EDMX models.  We’re using Self-Tracking entities, which means we don’t want lazy loading (because it will cause massive queries to be issued when the entities are serialized and sent over the wire to our WCF client) – so now we need to turn it off every time we spin up a new database context.  In my mind this is a general design flaw of the framework.  Lazy loading & disconnected scenarios (in which Self-Tracking entities are necessary) are meant for two very different styles of application development.  Yet they’ve mashed up the behavior into a single database context object.  I am very biased by my experience with LLBLGen Pro – its approach seems to make more sense to me - you have two ways to set up your project: you can either use Self-Service approach(which allows for lazy loading, etc.) and then there’s the Adapter approach (centralized fetches.)  These are very explicit boundaries – as I believe they should be.  Microsoft has completely muddied the waters with its decision to change behavior based on which version of the Entity Framework the model started from.

These are only a few examples of many that highlight how the Entity Framework team took on way too much, way too soon – without really understanding the problems they should have been trying to solve for other developers.  Their vision does not seem to line up with what the rest of the ORM world is doing (who else has a Conceptual –> Physical model? in v1?)  Who asked for this feature?  In theory (and in an ivory tower) it sounds great.  In practice they spent a lot aof time building a mapping system, designer, and a runtime to support this mega-feature.  What they should have been doing is building an ORM that had fewer moving parts, that behaved like its would-be real-world users expected.  Maybe I don’t understand the Entity Framework team’s vision. 

All I know is that I wanted a wrench, and Microsoft gave me a 20-tool multi-tool that doesn’t work as well as the simple wrench I already have.

For version 5, the Entity Framework team should get out of their ivory tower, go out to customers’ sites who've chosen NOT to use Entity Framework and see what they’re using, why and how they’re using it and incorporate these ideas into the next version.