Entity Framework 4 Firestarter: That’s a Wrap!


This post is a bit overdue, slightly out of chronological order, and will probably have me rambling a bit too much but I’ve been busy lately – so sue me 🙂

Earlier this year I was was asked if I wanted to participate in delivering the Entity Framework Firestarter event here in NYC.  I eagerly said YES and the planning began in late summer between myself, Julie Lerman and Rachel Appel.

Julie is the well-known author of the recently-released definitive work on Entity Framework 4, Programming Entity Framework, 2nd Edition.  Kudos to Julie for having the intellectual honesty to at least call her second book on EF “2nd Edition” instead of calling it “4th Edition” to correlate with EF4!  The picture provided at left is that of Julie delivering her (much more substantial and in-depth than mine) part of the day’s content on Entity Framework.

Rachel Appel is one of our Microsoft Developer Evangelists here in the NYC region and was instrumental in organizing the event, coordinating getting someone as well-known as Julie to speak about EF with myself, and also delivered a session at the event herself too.

The videos for the event will (eventually) be made available on MSDN Channel 9 but the slides are already available here.

Its The End of The World!

What’s that, you say?  The guy who swears by NHibernate as the best choice for ORM tools delivering talks introducing people to Entity Framework?  How can that be?  What’s next –?  Hell freezing over?  Dogs and Cats living together?  Flying Pigs?

Well, not quite…

The Importance of Speaking from Knowledge

While the internet and other media outlets seem intent on exponentially increasing the number of people enabled to criticize things which they haven’t taken the time to even try to understand, my own personal opinion is that about the only thing less valuable than opinion in uninformed opinion.  People who form opinions without bothering to do the hard work of investigation are a recurring pet peeve of mine.  So when it came to something like Entity Framework, I was determined that I was not going to be speaking from an uninformed point of view but wanted to really understand for myself the changes that Microsoft had made to EF since their initial release.

I was determined that I wanted to be able to speak about EF from a position of knowledge rather than one of ignorance.  But like just about everyone else out there, my time is short and (usually) over-booked so I needed a kick-in-the-pants to force me to learn EF4.  Volunteering to speak at this Firestarter event was that kick-in-the-pants for me – it provided me with a concrete time-frame within which I had to learn EF in sufficient depth that I could speak about it publicly without coming off as a complete moron (I suppose the reviews for my sessions will let me know if I was successful at this or not!).

And having access to someone like Julie with her unbelievable wealth of knowledge about EF4 to provide a safety-net for my learning was an opportunity almost too good to pass up.  When you have that rare chance to learn something new with the assistance of someone who is clearly an acknowledged master in the subject, you take it!

.NET Community, Meet ORM

Like it or not, the vast majority of the Microsoft developer ecosystem is populated by people who largely feel that until Microsoft expresses interest in an aspect of software development, its not worth their time to investigate or explore it.  We can complain about this all we want, but the honest truth is that this is probably an aspect to the Microsoft developer ecosystem unlikely to change any time soon.  Choosing to live and work within this environment means learning to deal with this element.  Not to like it of course, but just to acknowledge it and work with it.

That could mean that the right reaction is to throw one’s hands up in frustration and abandon the platform and the ecosystem as some have done (and I expect more to continue to do for these reasons and others).  But it could also mean that when Microsoft (even belatedly and kicking and screaming in many ways) eventually awakens itself to an area of software or technology somehow completely new to them but largely ubiquitous elsewhere, you need to try to seize that opportunity and make something of it.  Microsoft has now belatedly come to terms with what much of the rest of the software development world has long known: many, many data access problems are indeed best solved with some sort of object-relational mapping approach.  Entity Framework is the manifestation of that acknowledgement on Microsoft’s part (now that they’ve dropped the silly charade that “EF isn’t an ORM, but its something that you might use to build an ORM”, of course) 🙂

Just as with Unity when it came to IoC containers, MSTest when it came to unit testing frameworks, the REST starter kit for WCF when it came to REST, ASP.NET MVC when it came to (relative) sanity versus complexity in web application frameworks, and many more cases, Entity Framework isn’t a groundbreaking exploration into exciting new areas of these technology categories.  But that’s ok – when your customer base is near-totally dominated by Enterprise customers (and that’s where vast amounts of your revenue is derived), “trailblazing technologies” isn’t what you want to be known for.  Trailblazing scares big enterprises and scaring your customers isn’t a recipe for success – its a recipe for failure.  For Microsoft to do more trailblazing work would really require (among other things) a shift in its hierarchy of revenue – not something likely to happen any time soon.

But nonetheless, “where Microsoft goes in the .NET ecosystem, so goes the majority of developer mindshare” (like it or not) and so when Microsoft produces one of these things while they tend to never be the pinnacle of their category, they do have the indirect effect of ‘blessing’ each specific category of these technologies.

If Microsoft not having an entry in any one of these fields permits the lazy among us to explain away their ignorance of a technology, then it must follow that when Microsoft does enter one of these technology areas it tends to act as a verification to .NET developers that they need to begin to pay attention.

Unity did this for IoC containers; blog posts, podcasts, MSDN Magazine articles and more had to at least take the time to explain what IoC was and why you should care.  MSTest increased awareness of unit testing among .NET developers.  And Entity Framework increased awareness about ORM.  In a very real sense, this is the application of Kennedy’s phrase “A rising tide lifts all boats”.  To be sure, some developers won’t ever look beyond the Microsoft offerings in these categories.  But as awareness of these areas increases, an ever-larger number of .NET developers will begin to explore other offerings in these same categories.  And that helps everyone grow.

Technology is about more than Technology

But being introduced to a new developer technology needs to be about more than just learning an API.  It needs to be about learning the patterns of (successful) implementation that go along with a new technology.  Its possible to pick up EF, use the provided incredibly heavy-weight code-generation tools to produce partial classes that are intimately coupled to EF and know everything about their own dirty state, erroneously call these things ‘domain objects’, serialize them and transmit them between tiers in your application, and claim “I’m done”.  But in the end, just about every one of these things that EF makes ‘easy’ to do is a demonstrable anti-pattern in ORM techniques that just about every other software development community has long-since discovered and largely agreed are bad ideas to pursue.

If you take EF “out of the box” and do any or all of these things, its critically important to understand that just as when you follow other anti-patterns its not as though a lightning bolt will come from above and kill you dead.  But the reason that something is considered an anti-patterns is that it has been shown, again and again, to be a common approach to solving a particular software development challenge that results in repeated pain for you at later points down the road.

These effective patterns and ineffective anti-patterns in re: ORM are already well-established: value persistence-ignorance in your domain model, resist transmitting your domain model over the wire between tiers in your application, consider code-gen to be a last-resort rather than a quick-jump-start for your own code, and many more.  Somehow these patterns and anti-patterns need to get into the hands of EF adopters that are both ignorant of the EF API but also ignorant of the best (and worst) practices when it comes to using and ORM.

Because EF (unfortunately) tends to enable more of these anti-patterns than encouraging many of these patterns, its important for potential adopters to be exposed to the patterns and begin to understand them.  Its only through this process that enough people will begin to demand enough change to EF that it stands a chance of maturing as an ORM to the point where its possible to use it out of the box in a way that won’t kill all but the most trivial of projects.

The last session of the day for which Julie and I co-presented, Writing Testable/Maintainable Apps with EF,  demonstrated some of the ways in which its possible to abstract away your code’s direct dependence on EF and yet still gain most if not all of the benefits of EF in your projects.  And in the process this approach enables you to unit test your way around EF as well as ensure that your solutions remain easier to maintain and extend over time.  In essence, this session was an attempt to share some of the ORM patterns with the group rather than just demonstrating out-of-the-box anti-patterns with EF.

And since so very few .NET developers have significant experience with EF, they are effectively blank slates upon which we can either sit idly by as anti-patterns are imprinted upon them or we can take action to try to help them understand the patterns and why they should care about respecting them.

Its The End of the World (as we know it)

So I look at Entity Framework as an opportunity to increase awareness among developers about both ORM technology and effective ORM patterns.  Do I think EF is the best ORM tool out there for .NET?  Of course not :)  But do I think that increasing awareness of ORM concepts via EF will lead to increasing numbers of people seeking out more mature ORM frameworks?  You bet I do.

And the huge growth in the NHibernate download statistics each month since the release of Entity Framework 1.0 prove it.  And that’s why while EF has helped bring about the end of the world as we know it (the majority of .NET developers having no idea what ORM is), its hardly the end of the world in its entirety that I’m interested in trying to influence how most .NET developers approach their consumption of ORM in general and Entity Framework in particular.