I've been thinking about Entity Framework a lot lately, and I've been working with it as well. I got really deep into the technology when I created a course for AppDev titled "Developing Applications with Entity Framework 4.1." I had the pleasure of teaching the course last week to a group of developers at a municipality in Fairbanks, Alaska. The group had some really great questions and discussions about the practical use of Entity Framework in applications. We were also lucky to have one person in the group who had been badly burned by an earlier version of Entity Framework and its lack of support for round-tripping changes to the database. It's always great to have one person in a group being the cynic to keep me focused and keep things interesting (Thanks, Tom!).
Last week, fellow Dev Pro UPDATE columnist, Michael K. Campbell, wrote an interesting column about the trade-offs involved in using Entity Framework and other object-relational mapping (ORM) frameworks versus low-level data access programming with stored procedures. Campbell's column is written from the perspective of a DBA who's responsible for the scalability and performance of database servers. In addition, he also discussed the effects that Entity Framework and other ORMs can have on a server. Campbell mentioned that he typically uses a modified version of PLINQO, which is an ORM utility that I hadn't encountered before.
PLINQO is created by CodeSmith Tools. The company also developed CodeSmith Generator, which I've used off and on for years. PLINQO comes in three versions, one for LINQ to SQL (a technology that's now regrettably deprecated by Microsoft), one for Entity Framework, and one for NHibernate. The product includes a set of CodeSmith Templates that are "designed to simplify the creation and maintenance of data models" as well as providing users "with an easy to use data access layer that [adheres] to best practices." Best of all, PLINQO is free if you have a license to CodeSmith Generator. PLINQO is definitely something I'm going to check out, and I might use this utility in my next Entity Framework project.
Discussions about Entity Framework are increasingly important as Microsoft pushes the tool as its recommended data access technology. Although no tool or technology could ever be perfect for every scenario—what a bloated pig that would be!—Microsoft has made Entity Framework appropriate for several different scenarios over its five releases to date. Campbell's column hinted that Entity Framework seems to be bloated beyond where it needs to be. Support for other ORMs in the .NET development world seems to be as strong as ever, despite the inherent advantage that Entity Framework has by being a part of the .NET Framework and closely integrated into Visual Studio (VS). If anything, Entity Framework has raised the bar for all ORM tools; Entity Framework might be the first ORM tool developers encounters, but it isn't necessarily the one they will use for everyday work.
One of the problems with Entity Framework is that it's a beast to learn. If you never go beyond the Entity Data Model Wizard to reverse engineer an existing database and use entity data objects as they were generated, then there isn't too much to learn. But if you really want to take advantage of Entity Framework, then you'll have to roll up your sleeves and dig in to it. This includes exploring and understanding the XML language and structure of the three models—conceptual, storage, and mapping—as well as understanding entity object code that's generated in the designer.cs code file.
One example of something that Entity Framework supports but isn't very intuitive to discover or use is how to access current and original values for a property that's mapped to a field in a database. In order to do this, you need a basic understanding of the ObjectStateEntry object and how to access it. The following code shows one way to access these values for a customer object's FirstName property:
var currentvalues = context.ObjectStateManager.GetObjectStateEntry(customer.EntityKey).CurrentValues;
var originalValues = context.ObjectStateManager.GetObjectStateEntry(customer).OriginalValues;
var originalName = originalValues["FirstName"];
var currentName = currentvalues["FirstName"];
Console.WriteLine("Original value: '{0}', Current value: '{1}'",originalName, currentName);
The code is simple enough, but it's certainly not obvious unless you understand the objects supplied by Entity Framework.
So, where has all this pondering about Entity Framework gotten me? Entity Framework is worthy of consideration for use in any non-trivial data-based .NET application. But that doesn't mean that Entity Framework should be an automatic choice. Instead, as with all technologies, consider how and whether Entity Framework can strengthen both the application and the development process. I'm getting to the point at which I wouldn't ever want to go back to the days of hard-coding every data access operation in an application. However, this doesn't mean that Entity Framework has earned a spot in every application yet.
On a related note, I somehow missed that Julia Lerman's second add-on book to her must-read Programming Entity Framework: Building Data Centric Apps with the ADO.NET Entity Framework (O'Reilly Media, 2010) is out. The add-on books, which are co-authored with Entity Framework expert Rowan Miller, cover new features that have been released since Entity Framework 4.0 came out with Visual Studio 2010. The new book in this series is Programming Entity Framework: DbContext (O'Reilly Media, 2012). I haven't read it yet, but I'll take care of that later today. Lerman's work is always worth reading.
