Microsoft software architect Mike Pizzo announced in the ADO.NET Entity Framework Update post of 10:09 PM, Saturday, April 28, 2007:
[W]e have decided to ship the ADO.NET Entity Framework and Tools during the first half of 2008 as an update to the Orcas release of the .NET Framework and Visual Studio.
Mike does his best to spin the bad news by starting the announcement with:
Microsoft is deepening its investment in the ADO.NET Entity Framework as a critical piece of Microsoft’s Data Platform vision.
Many Microsoft observers will read that sentence as:
Microsoft is deep-sixing its investment in the ADO.NET Entity Framework as a critical piece of Microsoft’s Data Platform vision.
It's too soon to make that judgment, but there's no question that Mike's announcement delivers yet another blow to those developers (like me) who followed Microsoft's primrose path into its previous object/relational mapping (O/RM) tool void.
Microsoft MVP Scott Bellware avoided the most recent O/RM trap by abandoning a planned short-term implementation of the Entity Framework (EF), as described in his April 24, 2007 Falling Back to NHibernate - A Phone Call with the Entity Framework Folks:
We made a decision today to put an early end to our exploration of the Entity Framework for our current product work, and to fall back on NHibernate. ...
When the EDM designer started to drop out of the CTP's (post-August 2006), we had hoped that it would reappear around beta 1, and would be fairly solid around beta 2. We're scheduled to ship our current work product in coincidence with Orcas. We expect to start customer previews when a go-live license is offered. Without an editor for the metadata, we really can't justify the use of the EF to our customers.
The phone call [to the ADO.NET EF team] took place in two parts. The second part of the call got into some NDA-covered material that Kevin wasn't able to stick around for. Tim and Dan shared some info that gave me with a definitive and conclusive basis for making a sound call for our product. I'm very grateful to the EF team to have been enabled to make such a clear cut decision.
I have the feeling that Scott might have received advance notice (under NDA) that EF and its components were going back to the drawing board. Regardless, he said in an April 22, 2007 comment to my Persistence Ignorance Is Bliss, but Is It Missing from the Entity Framework? post:
I won't remain committed to the Entity Framework if the EDM Designer doesn't arrive by Orcas RTM.
I see the EDM designer as one of the most compelling features of EF in its current incarnation. It's the piece that translates well to how we expect our customers will expect to work with the entities in our product.
If the EDM designer is not in place by RTM, then I don't expect that we can ship a product to our customers if part of the product's customization story is based on the presence of the EDM.
We would need to fall back on NHibernate, and we have had this contingency plan in mind since we began the foray into EF.
Scott implemented his contingency plan two days later. (He insists he's not a member of the "NHibernate Mafia".)
Note: There still might be hope for EF with the Domain Driven Development (DDD) crowd. Interknowlegy's Tim McCarthy is writing .NET Domain-Driven Design with C#: Problem-Design-Solution to be published by Wiley. You can download the slides and code for Tim's April 19, 2007 "Domain-Driven Design using the ADO.NET Entity Framework" presentation to the International Association of Software Architects' Southern California chapter (IASA SoCal). The code is based on Paul Gielens original code for "Organizing Domain Logic" which compares Microsoft's Three-Layered Services Architecture (MS-TLSA) approach against DDD. (The three layers are the traditional data, business and presentation, not the EDM's storage, mapping, and coneptual layers.)
Does Microsoft Have a Data Access Strategy?
Mike posted Microsoft’s Data Access Strategy to the Data blog three minutes after the preceding bombshell. He answers the question with:
Yes, it turns out we do. Microsoft envisions an Entity Data Platform that enables customers to define a common Entity Data Model across data services and applications. The Entity Data Platform is a multi-release vision, with future versions of reporting tools, replication, data definition, security, etc. all being built around a common Entity Data Model.
Mike disclosed another part of the data access strategy in the first post:
Microsoft will be leveraging the Entity Data Model in future versions of Microsoft products such as SQL Server. This Data Platform vision enables customers to leverage their investment in a common conceptual entity model across product lines. [Emphasis added.]
Frans Bouma, the developer of LLBGen Pro, a commercial O/RM tool, has a different (and sinister) take on Microsoft's data access strategy:
The announcement speaks about Microsoft building applications on top of Entity Framework and also that the Entity Framework is moving towards SqlServer. Now, if you can add 1 and 1 together, you of course realize that if you have an application, say Sharepoint vNext, build on top of Entity Framework and you have one of your major cash cows SqlServer enabled with Entity Framework, you have a combination to earn more money: people who want the next version of your application also want your new database system.
The Entity Framework in ADO.NET vNext was designed to be database independent, and it might still be database independent when it eventually ships (I personally don't believe their H1 2008 mark). If you have one of your other major cash cows, say Sharepoint vNext, build on top of ADO.NET vNext, you then open up the road to host Sharepoint on say Oracle, DB2 or an open source database. This then would alienate one of your other cash cow products, SqlServer which will have the Entity Framework build-in.
Personally, I don't buy Frans' theory at present. Microsoft's "major cash cows" are Windows operating systems, the Office suite, and well-entrenched server-based applications, such as Exchange Server and SQL Server. By default, Windows SharePoint Services (WSS), which is a component of Windows Server 2003, uses freely distributable SQL Server 2005 Express (SSX) as its data store not as its host operating system.
Paul Wilson, the developer of the commercial WilsonORMapper (a simpler competitor to LLBGen Pro) says "Great News: Only One O/RM Shipping in Orcas." Wilson is a fan of LINQ to SQL because it's simpler but "good enough for the vast majority of cases."
Mike contrasts LINQ to SQL and LINQ to Entities:
LINQ to SQL supports rapid development of applications that query Microsoft SQL Server databases using objects that map directly to SQL Server schemas. LINQ to Entities supports more flexible mapping of objects to Microsoft SQL Server and other relational databases through extended ADO.NET Data Providers.
Despite the comments regarding support by LINQ to SQL for databases other than SQL Server by Dinesh Kulkarni, Scott, Guthrie, Matt Warren and Keith Farmer quoted in my Future LINQ to SQL Support for Multiple Databases? post of April 19, 2007, Mike has put that issue to bed. It's clear as part of Microsoft data access strategy that LINQ to SQL is LINQ to SQL Server (only).
Shades of WinFS, ObjectSpaces, Project Green, and the Microsoft Business Framework
The previous indication of trouble in the Entity Framework camp was the announcement at VSLive! San Francisco that the Entity Data Model (EDM) Designer had been cut from the Orcas release.
Earlier, a major controversy about EF's lack of "Persistence Ignorance" and its need to support Plain Old CLR Objects (POCOs), test-driven development (TDD), and agile programming techniques erupted at Microsoft's MVP Summit conference in Redmond on March 12 - 15, 2007.
But the real problem is that .NET developers might equate the result of EF's integration into the next version of SQL Server (code-named "Katmai") with the demise of ObjectSpaces, EF's ill-fated predecessor OR/M tool, when it was integrated into WinFS. My June 26, 2006 Microsoft Bites the Bullet: WinFS Bites the Dust post delivers the grisly details of the deaths of WinFS, ObjectSpaces, Project Green, and the MBF.
Here's Andrew Conrad's statement of the official status of ObjectSpaces in Visual Studio 2005 (then codenamed "Whidbey") as of April 6, 2004:
ObjectSpaces is not participating in Whidbey beta 1, however, it remains part of the Whidbey/Yukon wave and will be made available as a downloadable add-on pack for the .NET Framework Whidbey shortly after Whidbey ships. This additional development and stabilization period will be focused on improving the overall ObjectSpaces programming experience and providing tighter integration with WinFS, the next generation file system in Longhorn. The schedule for the ObjectSpaces mapping tool is also being adjusted accordingly.
His post concludes with:
Bottom line - this will mean some change in the release schedule, but should not adversely effect anyone's plans to deploy the ObjectSpaces framework. In fact, I believe the tighter integration with WinFS will significantly justify the delay.
Does that language sound familiar? Compare the comments with those to Mike's initial post.
Even more ominous is Barbara Darrow's April 26, 2007 speculation in CRN that "Katmai, Orcas Link Could Delay Longhorn Release." If true, which I doubt, Katmai's EF dependency could delay it and Longhorn Server until probably late 2008.
Mike replies with a Sunday-afternoon comment regarding spin, ObjectSpaces, and WinFS:
I apologize for the “PR-spin” feel people have associated with this post. Even a short delay of the Entity Framework is a difficult message, especially to convey through the imprecise nature of written communication. How do we convey that we believe this to be the right decision, without people losing confidence in the technology, particularly in light of Microsoft’s less-than-perfect record in shipping ORM solutions, and in the wake of WinFS? I struggled with the wording. With the approach. With the message. Yes, marketing was involved in reviewing the content (of course). I regret now accepting some of their input, but the message is the same. The Entity Framework will not ship in Orcas. It will ship shortly there-after. The slip isn’t about Microsoft’s lack of commitment to the technology. It does give us more time to address some key feedback we’ve received to date from internal and external customers, including providing at least CTP-quality tools for defining flexible mapping between the store and the objects. There’s no way I can convince you that this isn’t another ObjectSpaces, or another WinFS. You’ll have to look at how we continue to deliver over the next few months. You’ll have to look at the quality of the bits. You’ll have to look at the other investments Microsoft is making around the Entity Data Platform, including announcements and demos this week at Mix.
This year I celebrate my 20th year at Microsoft. In that time I’ve seen Microsoft invests heavily in a number of technologies that, for one reason or another, never come to market. This isn’t one of them.
I'm inclined to believe Mike's comment. NetDocs also comes to mind as an example of a well-funded Microsoft technology that never came to market.
"Those who cannot remember the past are condemned to repeat it."
George Santayana (1863 - 1952, The Life of Reason)
Mike says in his initial post, "Stay tuned for announcements starting next week at Mix around new products building on the ADO.NET Entity Framework." I plan to do this, but with trepidation.
Update 5/3/2007: Redmond Developer News senior editor Kate Richards quotes me in her April 30, 2007 ".NET Entity Framework Slips Beyond Orcas" article:
Roger Jennings, a developer and technology writer for OakLeaf Systems,
doesn't think the later ship date is going to be a big deal. "They decided that
they couldn't release the Entity Framework without the Entity Data Model
Designer, which was my contention to start with," he said. "And they've also
just announced a couple of incubation projects that depend on it that also might
have an influence on the delivery date." ...
"Almost everybody is considering [Entity Framework] to be ObjectSpaces
revisited, but I don't think that's the case," says Jennings.
The "incubation projects" are the ADO.NET Team's "Project Jasper" (a.k.a., Dynamic ADO.NET) and "Project Astoria" (a.k.a., "RESTful Data in the Cloud.)
Note: This item was linked from the Discussions section of the Techmeme entry for the original ADO.NET post. There's also a Discussions link to a Channel9 thread.
Atom 1.0 site feed
