Rejoinder #1 to "Vote of No Confidence in Entity Framework"

There's a "vote of no confidence" in Entity Framework petition that is circulating and, as I write this, it has drawn signatures of some 156 people. Many of them are well known, deservingly respected, and some of them I consider friends.

But this petition is wildly misleading. The dire warnings of "potential risks .. to Microsoft customer projects" are blown way out of proportion. It is one thing to be critical of EF v.1 - to draw attention to its shortcomings as we all have done - and quite another to consign it to damnation.

Tim Mallalieu, the new PM for Entity Framework, has written a careful response in the measured tones that befit a Microsoft representative. I, on the other hand, am not bound by such restraints and am free to indulge such rhetorical flourishes as suit my mood and temperament.

At the moment, I'm hopping mad. Every two-bit architect with visions of grandeur is going to send this petition to his boss as proof that Entity Framework will doom the project.

Hey boss, all these MVPs are against Entity Framework. Let me write our application with Domain Driven Design. I don't know a thing about it but how hard can it be? Of course I'll have to learn nHibernate first. Not sure how I'm going to do that. I can't seem to find a book on it. The documentation looks ok though. Well ... yeah .. I haven't found any examples or guidance on how to build a real application with it. But I'm an architect ... I'll figure it out.

Six months later our budding genius proudly shows off his ugly baby: some undocumented, impenetrable morass that only he understands and that works "most of the time", just not while you're watching. The application itself?  "Ah ... it's coming ... honest."

We've seen this over and over again and it is no accident. Some of my company's best customers found us after they cratered their first attempts with nHibernate.

I am not saying this is nHibernate's fault. It's great stuff in skilled and experienced hands. I am saying that there are risks with any choice of a profound technology and, before I lecture you on the "potential future risk to your projects," I would do well to find out about your business - and your developers - first.

Now I think there is a ton of merit to many of the criticisms of EF in that petition and much more to learn independently from the petition signatories.

But these folks are not coming clean about your prospects for building with some unnamed "something else." And, I submit, the chances of your success with EF are vastly better than with many of the alternatives that you are likely to hear about or pursue (including continuing with a traditional ADO.NET approach if that's what you're doing today).

Yes, I'm making a generalization without knowing anything at all about you or your business. And if you give me another minute, I'll tell you why you'll want my company's value-add product for Entity Framework. But before I get ahead of myself, let me try these thoughts on you:

• EF is going to mop the floor with all of the niche players. It will become the "standard" in this space. You want to throw yourself and your employer against that buzz saw? You better be able to show that something horrible is going to happen if you use EF instead. It is not enough to argue that technology 'X' is better. You have to show that the long term ROI of building with your pet technology is vastly superior to building with EF. You'll have to show that the EF defects identified in that petition are going to spell disaster for your project. Frankly, I don't think you can make either case. I'm not challenging your intelligence or persuasiveness. I'm saying the case is not there.
  
• There are thousands of successful applications built with frameworks like Entity Framework. I'm defining "success" here in soft business terms as in "the business likes it and thinks you are doing a great job". Don't stack the deck against me with Fitness tests (which are great, btw, but not implemented in most shops and irrelevant to the argument). Ultimately, business satisfaction is what we're striving for.
  
• We have zero empirical evidence that actually existing applications built with pure Persistence Ignorance frameworks are intrinsically more successful than applications built with Persistence Aware frameworks.
  
• On the other hand, there is good evidence that Persistence Aware frameworks are (a) easier to use and (b) result in earlier delivery of useable applications. You can start coding against an EF entity model almost out of the box. I'm not saying you should ... but you can. The fair proponents of Persistence Ignorance always acknowledge this when they talk about the "trade-offs" of PI.
  
• EF isn't even released and there is already more of an eco-system surrounding EF than around all of its competitors combined. Count the forum entries, magazine articles, and blog posts. Count the books on Amazon (six so far; ok, most not released yet ... but try to find a single published book on nHibernate).
  
• Expertise in EF will emerge quickly and spread widely as it always does with MS technologies. You will struggle today to find affordable developers and consultants who know about the rival niche technology of your choice; that situation is unlikely to improve as EF gains traction. 
  
• Some people will be good at developing with EF; some will be awful. But this is a numbers game and you can be an atrocious nHibernate developer too. The difference is that you will be able to find someone who can tell you that you have an EF fraud in your organization; nHibernate charlatans can hide like roaches.
  

... and from the "damning with faint praise" department ...

• I  eagerly accept that the evidence is overwhelmingly in favor of tested applications. EF is not unit test friendly (to put it mildly) and that's bad. They could have ... and should have ... addressed this in version one. But (a) you don't have to be PI to be unit testable and (b) you can build EF Domain Models that are unit testable (no visits to a database) as I will explain in a later post.   
  
• You can build your app with a DDD perspective ... you'll just have to work harder than you ought to.
  

Sure, I'm a proponent with an investment in EF (our new product is built on it). But the signatories to this petition are stained by compromises of their own. Many of them have deep emotional and even financial interests in rival "platforms" such as nHibernate (you have a financial interest if you've been paid to build an application with nHibernate).

Our little corner of the world would be better served if the petitioners rallied to (a) help customers make the best of EF version one and (b) got busy helping Microsoft improve it in version two.

---

Watch for a future blog when I examine the petitioners' "unresolved issues", point by point. They have merit. But they are not decisive objections and you can mitigate the problems, often with little pain.

Somehow I find I cannot end this post without dipping my toe into these waters. Let me start with the big one, DDD.

The petition avers that Entity Framework inhibits sound application architecture through its data-centric approach to mapping and code generation. We should be using Domain Driven Design and you can't do that with EF, so they say.

Eric Evans wrote the book on Domain Driven Design. It's a fantastic book; get it, read it, adopt it. Whether you're dealing with an existing database or starting afresh, you can benefit from Evans acute observations and analysis. But DDD is not a panacea and it is not trivial to apply.

Unlike his acolytes, Evans is the first to say that Domain Driven Design is hard. His is a book on perspective not on technique. Over and over he cautions that there is no machine for cranking out DDD applications. The practice of DDD is a relentless reexamination of the business problem and your implementation of it, punctuated by flashes of insight. What this book does is (a) prepare you for insights and (b) provide intellectual tools for unearthing and recognizing those insights.

Of course what does the industry do? It turns DDD into a cook book! You'll have little trouble finding someone with an MVP tacked to the end of his name, bloviating on DDD and what he knows that you don't.

Evans also makes the point ... several times ... that you don't have to adopt a particular data access infrastructure to build a Domain Model. Sometimes it makes sense, he says, to go with the infrastructure you have and bend it to your needs. Ideal? No. But serviceable unless the infrastructure is just crap.

For sure you do not enter DDD heaven simply by writing your domain objects before you write your database schema. Nor can any priest excommunicate you from the church of DDD because you map and generate Entities from your schema.

More soon ...

Update 6/25/2008 Added below:

I am looking forward to responding to the comments I've received so far, all of them remarkably well mannered. I'm going to get back to you all when I have a moment to breath. Meanwhile, I just want to direct your attention to these fine folks:

Tim Mallalieu, PM for Entity Framework, wrote the official Microsoft response and is showing a lot of love to the Persistence Ignorance fans these days on his blog and on the EF Design blog.

Microsoft's Elisa Flasko offers her views on her blog.

Roger Jennings has been following EF for a long time. He's been bulldogging links to "the vote" - adding his own appraisals of each - on his blog. He can save you a ton of time if you're trying to stay on top of what's happening in EF world.

Here's a shout out to Julie Lerman whose been in tireless pursuit of matters EF and who first clued me in to the vote in this post. She's a wonderful, level-headed resource on EF and a pleasure to read. Awful nice in person too.

Update 12/17/2008

I finally got around to addressing the five points of the "No Confidence Vote". I did so in a reply to Scott Bellware's comments on my  post, Is Entity Framework For Real?