Giorgio Galante

Let’s talk about the second reason to stay away from the Microsoft Entity Framework 4.

We can’t trust Microsoft to maintain backwards compatibility with (or future support of) previous versions of the Entity Framework.

Microsoft freely admits that they made a big mistake with Entity Framework v1.  So how do they rectify the situation?  By easily letting you upgrade your EF v1 project/model to EF v4, but completely changing the default behavior of the runtime.  I’m talking about the “new” Lazy-Loading feature Microsoft added to EF4 – it is turned on by default.  You can turn it off by altering the way you instantiate your context – have fun finding every instance of where you instantiate your context (we all know you should use a factory or DI container do this for you – but Microsoft makes a huge assumption here – that most people don’t just ‘new up’ their database contexts.)

I mentioned in the first post of this series that Microsoft is finally adding N-tier support in the Entity Framework.  That’s only partly-true.  The Entity Framework itself will not have self-tracking entities (typically required for N-Tier development) – this feature will be delivered in an out-of-band release.  I’m very apprehensive about being dependent on a Microsoft out-of-band release because time and time again, Microsoft drops support for these projects once they’ve moved on to bigger & better things.  Edit: 12/1/09 - As Danny Simmons commented below, the Self-Tracking Entities will be included in the .NET Framework 4 RTM.  This is good news.  Fortunately or not, your choice of ORM technology will affect and touch almost every part of a typical enterprise application. 

Microsoft’s poor track record in this space likely means yet another do-over at some point – and you don’t need to psychic to know how that story ends for teams that have chosen EF.