Vote of Confidence for Entity Framework 4? -- Redmond Developer News

More Redmond Developer Network Sites >>> VisualStudioMagazine.com | ADTmag.com | Events

RDN Express Blog

Blog archive

Vote of Confidence for Entity Framework 4?

Microsoft's data access strategy is built around Entity Framework, but is the .NET community on-board?

I talked with developers about latest version of the controversial framework, dubbed EF4, for the September cover story of Visual Studio Magazine.

Remember the ADO.NET Entity Framework Vote of No Confidence before EF1 was even released? That fervor has quieted down as Microsoft addresses some of the issues raised by the petitioners.

In EF4, Microsoft adds support for Plain Old CLR Objects (POCO) templates in VS2010 enabling persistence ignorance, lazy loading and better testing. All among the missing in the vote-of-no-confidence letter to Microsoft signed by 871 people in the summer of 2008.

Dane Morgridge, a Microsoft MVP for Data Platforms, wrote a technical sidebar for the cover story that explains how to use the new POCO templates.

"POCO support in Entity Framework 4 opens up the possibilities for architecting with repositories, if that's what you want to do, and doing unit testing and really building applications where you can have a good separation of concerns, which is really important when you're architecting large applications," says Julie Lerman, an independent .NET consultant who specializes in data platforms.

I was lucky to catch up with Julie Lerman, considered by many the expert on EF outside of Microsoft, and get her take on the second generation framework for the cover story, as she wrapped up the second edition of her book, Programming Entity Framework.

"It wasn't a simple revision, I spent a year writing it," says Lerman. "I thought second edition, no big deal--it took a year." The book is updated to cover Entity Framework 4, .NET Framework 4 and Visual Studio 2010.

You may be in luck. A discount on the e-book edition was slated as a one-day special on August 30, but the code was still working earlier today. You can get the e-book for $9.99 as a special deal from the publisher O'Reilly by entering the discount code DDPEF. Lerman shared other discount codes and options in her blog on Monday.

Read the cover story "Get Ready for the Entity Framework" here.

What's your take on Microsoft's data access strategy? Are you still writing your own data access code? Express your thoughts on LINQ, Entity Framework and n-tier architectures. Drop me a line at krichards@1105media.com.

Posted by Kathleen Richards on 08/31/2010 at 3:25 PM

Share this Page

Reader Comments:

Fri, Sep 10, 2010

Agreed above. ORM made developer like idiot. Low performance, take tremendous time to optimize.

Mon, Sep 6, 2010 Steve Naidamast USA

I am not a very big fan of ORM's or interim middle-tier tools that separate the front-end from actual data-access.

The problem with a lot of these tools is that they hide a lot from the developer while not offering much information when things go wrong.

A recent example is a set of remoting modules I have developed for my current client who preferred that I use the LINQ-to-SQL ORM classes.

I made a common mistake of passing some incorrect information that would tell the second of the two modules which data table to access. The result was a host of misleading errors that indicated a remote port issue instead of an actual database issue.

Luckily, and unlike my client, I had debugging tools installed on my own home-office network server and was finally able to track down the errors to the
database.

Had I continued to use my own standardized data-access-layer I would have resolved the issue immediately since it would have yielded far more accurate error information.

Out of habit I code my own mini-ORM into applications so that the higher level tiers in the middle-tier as well as the front-end modules can use object collections instead of datasets and datareaders. This technique comes from habit after so many years of having it drilled into your learning processes that you pass the least amount of information over the wires as possible, which lightweight collections do in place of the heavier ADO objects.

However, most ORMS attempt to do everything for the developer which incurs issues with re-mapping as well as less performance.

If a developer is still inclined to use an ORM, MIcrosoft's Entity Framework would be my choice over LINQ-to-SQL since you still retain the ability to work with basic object collections without the added baggage of an entire new access nomenclature, which will dilute existing knowledge bases that most developers already have and thus can implement far more efficiently in projects than starting with a new tool that does the same thing but in a different way...