LINQ and Entity Framework Posts for 3/2/2008+

Note: Items for March 6, 2008 were moved to LINQ and Entity Framework Posts for 3/6/2008+ due to excessive length of this post.

Microsoft Announces SQL Server Data Services at MIX08

Ray Ozzie's brief announcement of SQL Server Data Services (SSDS) at MIX08 might have been the source for Nick Carr's Rumor: Microsoft about to unveil web-apps strategy post of March 1, 2008 and follow-on Rumor: Microsoft set for vast data-center push of the next day. Other than SSDS, I'd have to agree with Joe Wilcox that Ray Ozzie Says Nothing New, Again.

For a synopsis of the scant documentation for and other stories about Microsoft's data-centric complement to Online Exchange and Online SharePoint, see my SQL Server Data Services to Deliver Entities from the Cloud of March 5, 2008. My conclusion is that the SSDS and .NET Data Services/Entity Framework APIs have diverged.

Added: 3/5/2008 Post updated: 3/8/22008

"Indefinite Hiatus" for Dare Obasanjo's Blog

Dare announced that his Indefinite Hiatus post of March 4, 2008 would be the last to his Carnage4Life blog that started as his kuro5hin diary in 1991. I've been an avid reader of Dare's blog since my early work with and articles and book about XML Web services. I'll miss reading his blog every morning.

Dare was the XML Schema program manager on Microsoft's XML team before moving to the Windows Live group. He's now a program manager on the Contacts & Storage team in Windows Live and has been writing primarily about social networking. I've been most interested in Dare's occasional posts about LINQ, RESTful interfaces, Atom, and other topics of interest to potential users of ADO.NET Data Services.

His early (1991) comment about XML while interning at Microsoft is interesting:

I've picked up XSD, XSLT & XPath while I've been here [at Microsoft] and am stunned by how complicated using XML has been made that almost every spec that deals with it is looks like it can only be fully understood by a Ph.D and is a few hundred pages when printed. Sheesh.

Ain't it the truth, especially for WS-*. (Dare says SOAP = Snakes On A Plane).

There was no word about the future of his Windows Live Spaces blog in the swan song, but Dare mentioned in an IM that it was only echoing his Carnage4Life posts, so it will probably go dark too.

Added: 3/5/2007

Bob Beauchemin Discounts Lack of Blind or Bulk Updates in LINQ to SQL and Entity Framework

Bob outlined six potential problems with LINQ to SQL and Entity Framework as "worry points" in his initial MHO: LINQ to SQL and Entity Framework: Panacea or evil incarnate? Part 1 post of February 13, 2008. The LINQ and Entity Framework Posts for 2/25/2008+ post has pointers to analyses of the first two:

1. LINQ to SQL and EF will proliferate dynamic SQL, and will almost surely produce suboptimal dynamic SQL, causing database performance problems and plan cache pollution. And dynamic SQL is evil to start with.

2. LINQ to SQL and EF will encourage "SELECT * FROM..." style coding because you get back a nice, clean object this way instead of the less-useful anonymous type you receive by doing projection. This will also make most/all covering indexes useless.

Bob's MHO: LINQ to SQL and Entity Framework: Panacea or evil incarnate? Part 3 post of March 1, 2008 tackles the third worry point:

3. LINQ to SQL and EF will encourage "SELECT to middle-tier, then update/delete" rather than issuing direct SQL UPDATE/DELETE statements that are set-based.

I, too, was concerned that EF's lack of DML for blind or bulk updates and deletions would impede its adoption. Bob concludes:

With stored procedures as needed and the realization that most apps use "GET then UPDATE" anyway, I think I'll dismiss this worry.

I agree. Blind and bulk updates in production online transaction processing applications are very uncommon. Because of the potential for serious data corruption, bulk updates should be done with stored procedures and preferably be planned and executed by a DBA.

Added: 3/5/2007

Note: Beginning with this post, links to topics in "LINQ and Entity Framework Posts for MM/DD/YYYY+" posts will include links to intra-page HTML anchors for the related topic.

I'll also mark individual topics as WebSlices when IE 8 gains a wider audience. Jon Udell's WebSlices can help popularize feed syndication post of March 5, 2007 has a great demo of the new WebSlice feature.

Sahil Malik Predicts: Entity Framework Will Become the Standard Architecture for Data-Intensive Applications

SharePoint and ADO.NET guru Sahil Malik's I told you so!! post of March 2, 2008 contains an important prediction:

ADO.NET eF - Will receive significant criticism, but will become the de facto way we write applications going forward.

I assume Sahil means "data-intensive .NET applications."

He goes on to explain his doubts about LINQ to SQL:

Microsoft's data access story: About 2 years ago, when I first played with DLINQ (now rechristened to LINQ to SQL), I basically flat out said - This is for RAD development/prototyping - not good enough for production environments. To be very specific, I had said ...

".... where your  logical model could be sufficiently disjoint from the conceptual model. So DLINQ (now LINQ to SQL) was ideal for situations where your logical model was very close to the conceptual model. Of course, you had better chances of finding a hot bikini model who was also a C++ programmer, than to find an application where the logical and conceptual model would be the same....".

I also expressed a more comprehensive opinion not too long ago.

Sahil also predicts the demise of technical books, that SharePoint vNext "will blow your mind," and Silverlight 2 won't succeed because it doesn't support search engine optimization (SEO). His other 10 predictions are far more vague.

Danny Simmons: More on the ObjectContext Lifecycle and Need for a Separate Data Layer

Danny's More about how to fit the ObjectContext into apps post of March 2, 2008 responds to Rick Strahl's suggestion to use one ObjectContext per business object, which raises obvious issues with associated entities. Danny recommends a single ObjectContext per session (or per thread for multithreaded apps).

He also says "no" to the question of "should you explicitly write a layer that hides all data access like we used to do?" The Business Objects layer he describes contains a combination of generated code for the ObjectContext partial classes and custom partial classes to implement business logic.

Danny concludes:

Of course there's nothing that says you can't write your own data layer which encapsulates the EF code that I described as the data layer, but for many applications I tend to think that will make your life harder for relatively little benefit.  One of the main reasons we would write a completely separate data layer in the past is that we wanted to isolate the business logic from changes in database schema and the like.  The EF now does that for you with its mapping layer.

The problem with this architecture is isolating persistence operations from unit tests for Test Driven Development, as Diego Vega discusses below.

Diego Vega on Test Driven Development with the Entity Framework

Diego's Unit Testing Your Entity Framework Domain Classes post of March 2, 2008 provides the following general guidelines for performing unit tests on an Entity Data Model (EDM):

• Encapsulate domain classes by factoring "all code that deals with IQueryable<T>, ObjectQuery<T>, and IRelatedEnd.Load()" into a "separate DAL component."
• Expose explicit data retrieval functions instead of ObjectContext<T> or IQueryable<T> objects.
• Eager-load associated entities for mocking (but lazy loading is OK for production).
• Mock with a "metadata-only" ObjectContext to gain persistence ignorance.
• Redirect SaveChanges() invocations to AcceptAllChanges() for tests.
• Create a new ObjectContext after the preceding action.
• Don't involve EntityKeys in business logic.

A few of Diego's recommendations appear to me to have internal or external inconsistencies.

Ian Cooper demonstrates the complexity of mocking LINQ to SQL DataContext objects with a repository model in his Architecting LINQ To SQL Applications, part 5 post of February 17, 2008. Similar problems are inherent to mocking the persistence features of an EDM. Ian provides more background on swapping from LINQ to SQL to LINQ to Objects and vice versa in his original Being Ignorant with LINQ to SQL post of June 10, 2007. See also my Ian Cooper Takes on DDD, TDD and PI with LINQ to SQL post of June 11, 2007, and the earlier (and longer) Persistence Ignorance Is Bliss, but Is It Missing from the Entity Framework? post of March 14, 2007.

Diego concludes:

It is actually premature to use the word “conclusion”. Mixing EF and TDD in the same pan is something I am only starting to think about. This is a set of scenarios that I want to see among our priorities for future versions.

In order to come to a real conclusion, I need to at least develop a sample application in which I apply and distill the approaches I am suggesting in this post. I hope I will find the time to do it soon.

I, too, hope he finds the time to do it soon.

New "Model Domain Objects with the Entity Framework" Article in Visual Studio Magazine for March 2008

Visual Studio Magazine's March 2008 cover story is my "Model Domain Objects with the Entity Framework" article. Here's the deck:

Microsoft's ADO.NET Team readies Entity Framework and Tools 1.0 for release as a VS 2008 add-in with enterprise-level features that LINQ to SQL doesn't offer—domain object modeling, flexible inheritance techniques, multiple database vendors, and do-it-yourself n-tier deployment.

The story covers new and modified EF features since my "Objectify Data with ADO.NET vNext" article in the October 2006 issue.

A sidebar describes Danny Simmons' EntityBag (Perseus) project for "do-it-yourself n-tier deployment."

Erratum: Entity SQL does have a JOIN command but it's used to join unrelated entities only. The eSQL NAVIGATE command is used with associations and navigation properties, which represent INNER JOINs at the conceptual level.

Repeated from previous week's post.

Technorati tags: ADO.NET Data Services, Astoria Project, Entity Framwork, Entity Data Model, EDM, Test-Driven Development, TDD, Persistence Ignorance, LINQ to Entities, LINQ to SQL, LINQ, SharePoint, Silverlight 2.0, Data Access Layer, DAL, Visual Studio Magazine, SQL Server Data Services, SSDS, REST, LINQ to REST, JSON, Sync Services, Microsoft Sync Services