Five months after the official release of Microsoft’s ADO.NET Entity Framework (EF) do we know where it stands? In particular:
· What is Microsoft’s commitment to Entity Framework?
· Is it good technology?
· Should you move to Entity Framework?
· Should you move to IdeaBlade’s “DevForce EF”?
Short answers: (a) total, (b) yes, (c) it depends, (d) it depends.
This is a piece I wrote recently to help our customers and prospects decide if they should use our Entity Framework-based product or stick with the more traditional approach of our "Classic" product. Clearly it is a promotional piece. I'm not shy about that; I'm darned proud of our product. But my blog isn't the the right place for that kind of thing.
I'm making an exception because several people who read it felt that my opinions about the state of EF deserved airing here. How can I deny them?
There are no fully adequate brief answers. I will give you a summary opinion now and then I’ll expand my observations and answer your questions over the coming weeks.
Entity Framework is the future of database access technology from Microsoft.
That may be hard to see. Microsoft announces a new data programmability option every six months. In the last year I count LINQ to SQL, Entity Framework, ADO.NET Data Services (aka, Astoria), SQL Data Services (not the same thing), Dynamic Data, and Azure Storage Services. Yikes.
These are actually a mixed bag of often interrelated capabilities. Who can keep them straight? In fact, of this set, only LINQ to SQL (L2S) and EF directly touch the data sources. The other services offer alternative modalities of client data access and themselves depend internally upon L2S or EF (or something else) for the “last mile.”
Microsoft recently merged announced that L2S is a dead end, smothered in the cradle. You can read about it here where Tim Mallalieu, the program manager for both LINQ to SQL and Entity Framework technologies writes,
“as of .NET 4.0, LINQ to Entities [aka, Entity Framework] will be the recommended data access solution for LINQ to relational scenarios.”
There remain plenty of non-“LINQ to relational scenarios” that call for raw ADO.NET. But the contest between pro- and anti-ORM camps has been decisively won by the pros. There is no discernable Microsoft action on “traditional” data access technologies.
Entity Framework was the data access technology on display at Tech Ed and PDC 2008, turning up repeatedly in talks about a wide range of subjects including cloud computing, the “M” modeling language, and Silverlight LOB application development.
With this kind of promotion and visibility it is hard to imagine Microsoft backing off or changing course. Perhaps they might if EF were an irredeemable catastrophe.
Is Entity Framework Good Technology?
In fact, Entity Framework is pretty good. And it’s getting better.
There is a small crowd of nay-sayers. Some of the more alarmists made their case in the widely noticed web petition called the "Vote of No Confidence". You’ll find my response on my blog where I say, in essence, that the petitioners grossly exaggerate both the deficiencies of EF and the benefits of their alternatives.
Is EF great? Not yet in my opinion. EF is still “version one” software so there are problems a plenty … and I’m not shy with my list of “turn offs”. Our “DevForce EF” product compensates for many of these problems but some of them will have to be worked through over time with a combination of upgrades, commercial products (e.g., ours), and community contributions.
Yet the EF core is rock solid and unequivocally suitable for most line-of-business applications. We’ve worked with it intensively for almost two years, starting long before its official release. If there were a rat to smell we would have smelled it and walked away long ago. Instead, we’ve bet our company on Entity Framework and so have many of our customers. One of them is building a software service on it that will reach more than 20,000 customers next year.
They are not alone but just how many have moved to EF remains a mystery. Microsoft hasn’t announced any numbers and they aren’t particularly good at this kind of counting anyway. My only figure comes from an October 2008 survey on Scott Hanselman’s blog in which 643 of 4900 respondents (13%) said they used EF. There is nothing remotely scientific about this survey but we’ll take what we can get; at least we know there 643 adoptees J !
Compare this with NHibernate adoptions. Ayende Rahien reports that, in September 2008, there were over 20,000 downloads of NHibernate and 1300 members of his “NHibernate Users” group. I rather doubt EF has 20,000 users yet; we can’t measure EF interest from downloads because EF was embedded in Visual Studio 2008 SP1 . On the other hand, I do think we can make some reasonable inferences about user community size by comparing his user group size to EF forum traffic.
A casual tour of the Entity Framework forum on MSDN reveals that post viewings routinely exceed; as I write there are three posts today with more than 1000 views – that’s a 1000 views in less than 24 hours. Is that a lot? Seems like traction to me and strongly suggests EF is already overtaking the field.
Should You Move to Entity Framework?
The consultant in me knows to say “it depends”. I think the major dimensions for consideration are:
- The nature of your application
- Your freedom to control the database schema
- Your willingness to lead
- Your reasons for choosing EF
In my view, EF could be right for you if … :
- You’re building a significant line-of-business application – one with plenty of user interaction and complex, interrelated data. By “significant” I mean an application you’ll spend more than a year developing.
You are thinking seriously about building a Silverlight client for your application, you should strongly consider Entity Framework; your best Silverlight data programmability options are going to rely on Entity Framework.
- You control the database schema. EF excels at mapping objects to existing databases but there are some peculiarities that are best resolved if you can change the schema. You also must beware of very large entity models. I’d hold off for awhile if you think you’re application domain is over 500 entities. I hasten to add that your design needs some serious rethinking if you’re entertaining a domain model with that many entities.
- You are prepared to be at the front of the adoption curve. EF quality is great – it is not buggy. But you are going to take some lumps and it lacks the wealth of knowledge and experience that surrounds more mature technologies. We are all going to be doing “stupid things” for awhile.
- You have a sound business reason to use Entity Framework. If your application is already built upon an existing object relational framework and you are reasonably content with that framework, I don't think I'd move to EF right now. Yes, it makes sense to migrate to what will surely become the industry standard platform. But today may not be that day.
On the other hand, if you are starting fresh, I believe it is foolhardy to consider any other object relational platform. I am not making a technical case. For the sake of argument, I will stipulate that there are several other choices that are technically “better” than EF … and I don’t have to know what you are doing to say that. Because it doesn’t matter.
You are making a business decision and you want to weigh heavily the benefits to your organization of going with the industry leader, with a product whose mind share and market share will most certainly be preeminent one year from now. Think about that. Think about future development on your application and what you will have to do to find and develop the expertise necessary to maintain and grow your application.
This is almost a good enough reason to migrate today. For some folks, especially those who are about to substantially enhance an existing application - I mean a serious, long term investment in extending that application - the business reason is more than good enough.
Maybe I’d feel differently if some alternative were dramatically better than EF or if EF were going to let you down. But no alternative is that much better and EF won’t betray you. EF is good enough today and with Microsoft’s unmatched resources and commitment, EF will only get better.
Should you move to IdeaBlade’s “DevForce EF”?
Heads up! This is the shameless commmerce section.
I said “it depends” and it does; it depends upon your answer to the previous question.
If like most of our customers, you are happy users of an existing ORM solution, this is probably not the day to switch to Entity Framework or DevForce EF.
If you are starting a new project but Microsoft’s EF immaturity gives you pause … listen to your gut. I’d be happy to suggest techniques that position you for an EF future while writing with our “Classic” product today.
On the other hand, if you think Entity Framework is right for your next project, you owe it to yourself to consider “DevForce EF”.
This essay isn’t really about our product; I recommend you go to our website to learn more. So let me give you the story in a nutshell:
DevForce EF is thoroughly grounded in Microsoft’s Entity Framework. We share exactly the same entity data model file and we rely on EF to perform all persistence operations. You don’t surrender an iota of EF capability when you adopt DevForce.
But DevForce EF will save you months of application development time and help you build a far better application than if you proceeded with EF alone because DevForce EF
· extends the Entity Framework with capabilities you need,
· compensates for many of EF’s deficiencies today,
· makes EF easier to learn and use correctly.
And if you are considering a future with Silverlight, know this: DevForce EF is the only way to take full advantage of Entity Framework on the Silverlight client. Yes, that’s an extraordinary claim; but it ain’t bragging if it’s true. Make me prove it to you.