ADO.NET Entity Framework (EF) is the new standard for data access in .NET Framework 4. This second iteration of EF, dubbed Entity Framework 4 (EF4) to align with .NET 4, is absolutely up to the challenge.
When EF was released as part of Visual Studio 2008 Service Pack 1, Microsoft focused on a single set of developers: Those who were working with legacy databases and who were manually transforming database results into their domain objects. These developers might or might not have been using DataTables from one end of their application to another.
This new framework came with a message from Microsoft: The EF would be the core data access tool for .NET development going forward. LINQ to SQL and DataSets would remain the same, but they would see no new innovation. Many developers took the plunge into the unknown waters of EF, and it wasn’t easy. There was minimal documentation; samples were rare; and guidance was non-existent. To developers unfamiliar with the EF rules of engagement, the EF runtime behaved in unexpected ways. Developers who had experience with Object Relational Management (ORM) tools found EF lacking. Developers who depended on strongly typed DataSets were simply frightened. DBAs were suspicious of EF’s command generation, and enterprises that depended on a myriad of existing stored procedures quickly hit a wall and walked away.
But the lure of learning something new was still very appealing to many. I fell into this camp as a long-time data geek. I ignored the widely expressed concerns that EF would never see the light of day and spent quite a lot of time exploring the framework. I learned how it worked, relearned how to access data, and eventually took all of that knowledge and wrote an 800-page book. I also forgot how to write T-SQL along the way.
Still, the reality of deploying EF was problematic. The word on the wire was to wait for the next version.
And it was worth the wait. EF 4, released with Visual Studio 2010 and .NET 4, embraces a variety of development styles. In a DevProConnections article, “Renovations to .NET 4.0’s Entity Framework,” InstantDoc ID 124925, I covered several categories of new features:
- For DBAs and developers with large legacy databases, the stored procedure support has improved. Most notably, the designer lets you easily implement stored procedures with results that do not match an existing entity. DBAs will also appreciate the greatly improved command generation.
- For developers working with legacy databases, the designer automatically applies singular and plural names where they make sense. EF now supports having foreign keys as scalar entity properties.
- The EF team completely rethought the code generation used to create classes based on the Entity Data Model entities. EF now uses T4, the code generation tool that has been part of Visual Studio since 2008. With T4, customizing the generated classes is easier and gives developers a whole new level of control over their entity classes.
- Another big boon to developers is the additional support for working with disconnected data in web applications and WCF Services. And for those DataSet lovers who just want services to work out of the box there’s a special feature called Self-Tracking Entities.
- The most prominent addition to EF4 in my opinion is its support for simple objects, aka POCOs, which allow developers to benefit from EF’s querying, change tracking, and database persistence, without requiring that your domain objects be completely bound to the EF. This allows developers to architect applications that separate the various concerns (presentation, domain objects, application, services, data access) as well as incorporate proper unit testing into their development.
With these and many other changes to EF, it has been exciting to witness the excitement of developers when they see EF4. Whether they had struggled with, ignored, or simply hated the first version (yes, there was some passionate reaction to the first version of EF), the new EF appeals to a much broader group of developers.
With this new version, EF absolutely justifies a second look. I hope that you, too, will be excited by what you find in this iteration. Be sure to read my article and Patrik Lowendahl’s article in this month’s issue to help you evaluate EF.