Entity Framework, The Five Years Plan, And Building Software on Future Features
When Entity Framework came out, there was a lot of excitement, and a lot of people picked it up. I was fairly confused about that, because I didn’t really understand why. One of the major reason that people kept saying is that “it might have problems now, but we are doing this to get an early start for what comes down the road”.
Indeed, at the time, Microsoft has some really interesting plans for Entity Framework and EDM:
Long-term we are working to build EDM awareness into a variety of other Microsoft products so that if you have an Entity Data Model, you should be able to automatically create REST-oriented web services over that model (ADO.Net Data Services aka Astoria), write reports against that model (Reporting Services), synchronize data between a server and an offline client store where the data is moved atomically as entities even if those entities draw from multiple database tables on the server, create workflows from entity-aware building blocks, etc. etc.
I emphasized some parts of that, because I think it is really interesting to look back at those statements in hindsight. We are about 3 years after the fact, and we can see that most of those promised projects actually came about. None of them actually uses the EDM, however. At the time, however, there was a lot of talks and plans about That One Model and how you would define it once and use it across all Microsoft products. I even recall one DotNetRocks show how SQL Server is probably going to move from the relational model to the EDM Model, as part of a company wide effort to go to a Model Based architecture, etc.
This is important specifically because of the ending statement of the blog post.
So the differentiator is not that the EF supports more flexible mapping than nHibernate or something like that, it's that the EF is not just an ORM--it's the first step in a much larger vision of an entity-aware data platform.
What actually happened is the landscape of database tooling in 2011 is drastically different than it was in 2008. The needs ,requirements and usage scenarios are changing with respect to the Cloud, No SQL, Sharding and more. One of the oft repeated phrases about Entity Framework at the time is that it is not an OR/M, it is so much more than that. Go and read the recent posts on the EF Design blog. You will see a lot of stuff about Entity Framework as an OR/M. You’ll see none at all about the “much larger vision of an entity aware data platform”.
That isn’t actually surprising, many of us in the community called out the impracticalities of such a vision at the time.
The point of this post isn’t to pick on Entity Framework, (in hindsight, a lot of the furor about Entity Framework seems overblown, actually) but it is to talk about something that is quite important.
It is very easy to talk about what you are going to do in the future, there is no actual commitment there, you can plan however you like, but the further in time you go, the least likely those plans are going to happen. Not because whoever made those plans lied, but simply because circumstances change. And when that happen plans are either going to change or become irrelevant.
The other aspect of this to that is that you should very rarely try to base your own decisions on what someone else is saying that they are planning to do that far down the road. Especially if it means that you are going to take a currently inferior product just so you would be familiar with it when it becomes great (part 23.13.B, section 12A in the Grand Plan). You should base your decisions on the current and upcoming stuff, not stuff that is so far in the future, the entire industry is going to change twice before the due date.
Sure, you probably want to keep an eye on what is going on and what the future plans are, but it isn’t really a good idea to base your decisions on that. I mean, if you were listening to the 2008 PDC, you would have bet the farm on Oslo…
Comments
Glad to see this post after our discussions in kharkov :)
5 year plans either don't work or you alter reality to fit them.
Not meaning to play devil's advocate here, but....erm...did...errr....somebody say HTML5?
I agree,
"The Best Way to Predict the Future is to Create it" -- Abraham Lincoln
-- s.
Very well put. Then again, if you are one of the few to gamble well ahead, and it does pay off, you win.
What you say is surely true. It makes no sense to build anything that depends on planned things for the future. Even Microsoft sometimes comes back down to earth and starts refocusing on reallity. But this must not in any case be a bad thing. If I look at EF today, I think it is a good and easy to use OR/M with a versatile team and community behind it. Sure, nobody knows how it will develop in the future, but as you say, you will never know, no matter what product you use...
Inexperiences programmers often tend to do too much generalization because "it saves so much code". But experience tells that once you have an exception to the general case it can be very hard to get out.
Their grand vision of "one data model" reminds me of that.
ashic -> HTML5 is already here. Regardless of the idea that there is or is not an official spec. It doesn't matter. The correlation is highly unfounded. The EF started as one thing, and had to completely alter itself. In so many ways it started as a joke, and only now has some credibility. HTML5 is a spec, of basically a bunch of stuff people already knew they wanted and would get. It is about collaboration, where as the EF wasn't.
Just pointing out, that the two are apples and oranges.
Interesting to see EF in its current state, versus the plight Microsoft originally gave it. I called BS then and am glad I did. I'd have sunk more than one ship if I'd ran with it back then. I use it now, some, but primarily as a quick and dirty CRUD generator. Otherwise I still use NHibernate or other options (re: Object/Graph/Doc Databases).
Great write up and quoting of tech history! ;)
@Adron: EF has credibility? Since when?
@Adron: How is NHibernate better then EF Code First?
NHibernate is a much more mature product that benefited from lots of experience in the field from many folks.
It simply has extension points that Entity framework doesn't currently support. Perhaps in time, it will provide a better extension mechanism as was the case with code first support.
Ayende, didn't MS give these some long range plans as the reason for not throwing its support behind NHibernate? Something to do with not wanting their "one model" plan to be based on open source software that they don't own. The same way they supported jquery, they couldn't have provided some support to NHibernate.
Yawn, smack, smack, zzzzz... Bob and KISS win again. ADO.NET and SQL still work as well as they ever did.
@Adron: I know, I know...what I meant was people did HTML5 a couple of years back. Back then it was in a state as bad as early EF days. Not saying I don't agree with the article though.
I actually do use EF code first for quick and dirty CRUD. It's not ideal, but it's good enough. For complex or mildly complex stuff, I choose to use event sourcing. If a relational model is complex enough to "exceed" EF Code First, it's a sign of one-model-to-rule-them-all :)
@ayende: Dude, your recaptchas are killing me here...any chance of taking a difference approach?
@ashic we once used recaptha on a client's website, but had to replace it because there were so many complaints from visitors who found the text in the images unreadable or too hard to enter on a keyboard.
Hey I know exactly wha you are talking about. We once choose NHibernate over EF based on the assumption that it will have usable LINQ provider in version 3.
not to say your overall point necessarily isn't valid, but doesn't ADO.NET/WCF Data Services/OData still use the EDM?
Comment preview