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.
Microsoft’s Commitment
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.”
You can learn more from Julie Lerman and L2S developer Damien Guard but Tim’s statement settles it for me.
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.
9 comments:
Do you get kickbacks? EF blows.
600+ people, many of which are highly skilled and respected developers all agree that EF is lacking in too many areas for them to even consider it.
I don't consider that a small portion of the community. I consider it to be THE community.
So, you're whole approach to addressing one of the most cohesive communities of practice in the pursuit of software development knowledge and excellence is to say that we exaggerated the deficiencies of EF and the benefits of their alternatives?
I'll speak for myself here and solemnly swear before my god, my faith, and my community of faith that I personally neither exaggerated the deficiencies of EF nor the benefits of it's alternatives in authoring the text of the vote of no confidence.
Does that means that my decision to foray into advanced software engineering and design practices rather that sticking with the INETA doctrine have led me to disillusionment, even though my understandings have been substantiated by software communities both inside and outside the Microsoft sphere of influence.
Ask yourself... do you really understand what we mean by local optima? Do you really, deeply, and meaningfully understand what we mean by TDD, and have you proven this through extensive practice and work wthin a learning organization? Do you deeply understand what we mean by incremental and emergent design when we speak of these things from the perspective of our experience?
Don't you think it just might be valuable to do what many of us have done in the name of knowledge and learning and trade your time at an advanced learning organization and really get a meaningful understanding about what we're talking about?
Speak to Jeremy. He would likely be amenable to having you as part of a knowledge exchange at Dovetail.
Otherwise, you're just talking from a speculative perspective. You'll need to stand in our shoes as long as we have stood in yours in our previous incarnations before we can really have a dialog worth the wasted water vapor that it's written on. Until then, your opinions can't have more weight than opinions.
Back your ideas up with experience - and not experience with those safe Microsoft pretenders. You know where the real deal people are. Go work with them. If you're really dedicated to this dialog, then get of your ass and become a seeker.
@anonymous - Yes, I get 10% of every EF license $. You've got me in stiches with your declaration that the signatories are "THE community". Really ... you're killing me.
Hey, I did make it clear that my company's latest product is built on EF, right? I didn't hide that. May I add that we embraced EF and continue to be pleased to have done so.
@Scott - Thanks for the extended comments. I take them seriously.
I never doubt your sincerity so there is no need to appeal to unnatural forces. I remain of the firm opinion that you did exaggerate EF’s defects.
Strictly speaking you are correct about one thing; you did not exaggerate the benefits of alternatives. Your petition does not really explore alternatives. I wish it had. Instead it takes 5 hacks at EF.
I’m going to get into those in a minute but first I want to address your suggestions for my personal growth.
You know I’ve dated TDD but I can’t say I’ve had that “really, deeply, meaningful” relationship with her that you so lovingly recommend. But seriously, I would thrill to the opportunity to work with and learn from Jeremy and Greg and Ayende and the many other folks with whom I find myself in occasional, passionate disagreement. They care about the craft. They think hard and creatively about the issues. They are, as you say, “real deal people”. The time will come.
Meanwhile, I shall flatter myself with the thought that our readers are more persuaded when we reason about a subject than when we claim membership in some club. In that spirit, I shall describe in detail what I believe is true and what I believe is exaggerated in the five points of your petition.
Claim #1: Inordinate focus on data aspects leading to degraded architecture.
Brush aside all of the philosophy in this section and your indictment is what? That EF “focuses on data storage … at the expense of … business rules and business logic.” How so? What framework are you talking about that does anything for business rules other than carve out the space for the developer to write them? There’s nothing in NHibernate to help you with business rules. All such object-relational frameworks focus on data storage; that’s their job.
Your best argument might be that EF somehow interferes with development of behavior-rich domain objects. You pursue that angle in claim #4; but not here. Here you simply assert that “Entity Framework is not optimized for this scenario.”
It seems to come down to the “workflow implied by” EF which is not supportive of entity development in a “behavior first” manner.
I share your preference for “behavior first” and agree that EF v.1 is far better suited to a “data first” approach. However, I don’t think our mutual preference for “behavior first” translates into much of a predictor of project success or failure. People have been building apps in the “data first” manner for as long as I can remember. They succeed. They fail. But when they fail, this methodological choice is rarely (if ever) to blame. You’ve seen the lists of reasons projects fail; have you ever seen “data first” workflow mentioned among the top ten causes? I haven’t.
Meanwhile, shouldn’t we acknowledge that a great number of people have existing databases? In many cases, the database schemas are “frozen”. Frozen or not, there are demonstrable productivity gains from generating “first cut” model classes from an existing database schema, especially if it is large and relatively mature.
I don’t know about you but I have tried to get customers to write domain objects first and worry about the database later. They just don’t go for it; not often anyway. They want the comfort of “real data” on that screen especially when they have an existing database. Often this is essential to selling the project to stakeholders. I could throw a fit about it … but I prefer to move on.
Moreover, in my admittedly limited survey of actual “design first” models, it appears that real business logic rarely arrives until long after the model has been mapped to a database. You can say “they’re doing it wrong” but if that’s what people are actually doing … then we might as well face it.
I think you’ve exaggerated the danger of a “data first” approach. If the approach were “data only”, you’d have a point. But you can introduce the requisite business logic coming from either direction. The genuine problem is that developers too often fail to think carefully about their domain models at all; such thoughtlessness cannot be cured by changing the direction of the workflow.
Claim #2: EF doesn’t support lazy loading.
It doesn’t and the failure to support lazy loading reflects poor judgment in my view. I understand that there were competing principles at work. One principle says that a property should return immediately; else you should use a method. This principle militates against lazy load because one cannot predict when the property will return its value(s).
On the other hand, everyone expects a property to deliver what it announces it will deliver. When I write Order.LineItems, I expect line items. Why would I ever call that property unless it returned those items. And then there is that other principle, the one that says a property should behave predictably and always return the same result. It shouldn’t give me items on one occasion and an empty list on the next.
Finally, there is tradition; every other ORM on the planet implements lazy load.
So they got it wrong. What do we make of it? In my view, this mistake is annoying but not disqualifying. You’ll find workarounds on the forums that hide the problem effectively and you can always use our product (smile) which does lazy loading for you. I really think you’ve blown this defect out of proportion. It is not a sufficient reason to avoid EF.
Claim #3: EF promotes a canonical model
If this were true it would be a marketing defect and not a failure of EF itself. In five paragraphs on the subject you don’t pin a thing on EF.
I cannot join you in saying unequivocally that “using separate models for each individual context in which a canonical data model might be used is the least complex approach, is the least costly approach, …”. There is nothing inherently wrong with using the EDM to describe a conceptual data model for use both within application code and within its companion reporting services. Doing so is often simple and cost effective … otherwise people wouldn’t do it.
There is risk of course. There is bound to be trouble when there is at best a pseudo-consensus among the data consumers regarding the meaning of the shared data. This is a problem for the database as much as it is a problem for the conceptual data model.
But it is an exaggeration to suggest that separate models cure all. Explain to my financial clients, if you dare, that there is greater efficiency, productivity, and maintainability when the “Customer” entity – the company’s most valued asset - appears in 17 different models.
Finally, if you insist, you can always write a different model for every context; no one is holding a gun to your head.
Claim #4: Lack of Persistence Ignorance leading to an anemic data model.
EF neither necessitates nor encourages an anemic data model. True, the generated entity classes lack behavior … as generated classes always do … but they are meant to be paired with a partial class file that holds the behavior. You may think little of this approach but it works and is manifestly a vehicle for turning simple entities into domain objects.
You want to say it “adds some awkwardness to the code”? Ok. I prefer that awkwardness to the awkwardness attendant upon PI: externalized change tracking, properties that must be virtual, proxies, inadvertent property invocation during reconstitution, etc. The fallout from that nonsense intrudes upon my application development.
I understand that some people - reasonable people - find a framework with high Persistence Ignorance more agreeable. I do not accept that a Persistence Aware framework necessarily “impairs a team’s ability to accurately model the behavioral logic of a system”. PI-ness alone is not decisive.
What is true is that, in EF v.1, you cannot easily exercise your EF domain objects without connecting to a database. Until you take steps to break this dependency on the database, your pace of development will be slower than it should be. This is, indeed, a serious problem … more so than most people recognize. You don’t have to be a TDD aficionado to feel the pain. On this point you exaggerate not at all.
The good news is that you can work around it by fronting your domain object access with a “repository”. The real implementation goes to the database; the fake simulates a database in memory for testing. Plenty of folks are doing that today.
Better still, you can use our DevForce EF product which makes it easy to test your model without connecting to a database. I maintain that you can test your model more effectively with our product than you can with, say NHibernate, because we provide an in-memory database experience - queries, navigations, changes, saves - for free; it’s a by-product of our queryable client cache. And I remind you that our product is based on Entity Framework.
So on this, EF’s most vulnerable point, it turns out that it is not as broken as claimed.
Claim #5: Merge conflicts with source control
The “problem” is that the XML that describes the drawing of boxes and lines on the canvas of the visual designer can be corrupted during a merge of changes by multiple developers.
I’ve never experienced this problem myself. But I just tried a simple experiment. I went into the XML and erased everything between the < diagram /> tags. Corrupted or not, who cares; I just threw the whole section away. I think it’s a waste of time to pretty-up the diagram anyway.
I reopened the designer … and it reconstructed a diagram for me. No big deal.
The real concern in this department is EF's visual designer. It doesn’t work very well. The moment you have a model of any size - say 30 entities - the layout becomes an eye-chart. It’s hard to find things; it’s hard to get around. The association mapping is unintelligible. Maybe they’ll get it right in v.2.
I’ll say this for it: it’s nice to have an EDM editor rather than be forced to edit raw XML … which is pretty much what you get with many ORM alternatives.
Oh … I should mention that our DevForce product provides an EF mapping tool, a Visual Studio plug-in, that I think works better for larger models. You can edit the EDMX with EF's tool or our tool or both tools. I predict other third parties will offer editors as well. Once EF takes off there should be a nice little market here.
--
So you see I’ve acknowledged that EF has problems. I’m not sugar coating it and I'm not an EF suck-up. You might prefer to use a rival product, at least until EF is more mature. I still recommend that you think carefully about the business consequences as well as the technological trade-offs.
We all should encourage the EF team to be more supportive of TDD and “design first”. But understand: there is nothing outrageous or insurmountable in this inventory of concerns and it is wrong (in my view) to try to scare people away from EF.
And you might try being more humble about the (implied) superiority of any available alternative.
Yeah, if we could keep the irrational jesus-freakery out of this, that'd be awesome.
I've been trying to twist EF into something usable for about 3 months now. I'm not doing this because I want to, I'm doing it because I have one of those dumb clients who sucks at the teat of M$ without thought or reason.
Kind of like your blind enthusiasm for this broken technology.
If I were doing something really, really dumb, this might be a handy library to have around. As it is, making it function in any real business situations is like pulling teach.
I have spent 2 weeks to explore features of EF. And I have wasted my time.
T
Hi Ward,
You say:
"The good news is that you can work around it by fronting your domain object access with a “repository”. The real implementation goes to the database; the fake simulates a database in memory for testing. Plenty of folks are doing that today."
Isn't wrapping the EF in a Repository kind of a cop out or am I missing something?
If the repository returns a set of independent custom business objects and insulates you from the EFs EntityObject classes then you wouldn't be able to do all the really neat things the EF objects allow, like LINQ to Entities and change tracking. You wouldn't be able to even navigate associations.
Sure it would solve the testability issue but you might as well not even be using the EF since your business layer and higher layers can't leverage any of its benefits.
Or have I misunderstood what you meant by using a Repository?
BTW, just listened to your show on DotNetRocks. Great show!!
Any approach which focuses on something besides "domain" is, by definition, a technical focus and not a business one.
By this, I mean that "data-first" implies "data-first, then behavior", which factors concerns to "data, then rules", which places your priorities at "database, then business value." Explain to your clients, if you dare, that you are placing their business concerns behind your technical concerns.
Data-first means taking the problem as you currently understand it, projecting the results of rules you haven't defined yet, and then instituting what can only be considered a "best guess" schema. The implicit assumption is that business rules can be retroactively fitted because they are implied by the data they act on and produce.
I argue that the opposite is true, that only by defining business rules do you discover relevant data and its relationships. That is the core of TDD, a discovery process for your problem domain.
If you make the assumption that you can discover most everything up front, it is then natural to create a database and classes and go from there. Unless you are really, really good (which I'm sure you are, Ward) you will eventually be crushed under your own inertia when your understanding of the problem changes. That is the danger of non-domain-first development.
Post a Comment