8.16. Dane Morgridge

http://geekswithblogs.NET/danemorgridge

I have been using ORM tools for several years and decided to take a look at EF when it was released with .NET 3.5 SP1. Previously, I had been using LINQ to SQL, and given their similarities, moving to EF wasn't difficult. The first version of EF was missing quite a few features that were present in most ORM tools, mainly lazy loading. I tend to personally prefer to preload as much data as I can, so not having lazy loading wasn't a huge problem for me. One of the biggest problems I ran into was the fact that you didn't have direct easy access to foreign keys, which required you to pull back additional data to get basic relationship data. Other than a few API differences, this was the biggest pain point in moving from LINQ to SQL to EF. Despite these issues and EF's critics, I have grown to love EF and have been using it in production since its initial release.

There are really two paths into working with EF: those who have used ORM tools before and those that haven't. Those who have used ORM tools before will quickly notice the features that are missing and may be a barrier to adoption. Those coming from normal ADO.NET development will likely not miss the features that aren't included, since you can't do things like lazy loading with ADO.NET datasets or inline SQL. Version 4 of EF will be a game changer. I have been working with VS2010 since the first public beta and I am very happy to see where EF is going. The product team has been listening to users, and a majority of the issues with the first version of EF have been addressed with version 4.

I am personally very excited about the features that allow for persistence ignorance, like POCO classes and self-tracking entities. When building services and web applications, I like to have a data layer that is ignorant of the database. This is for multiple reasons like reducing the amount of data that goes over the wire and being able to use the same classes on both sides of the service. With version 1, I have to write my own additional layer to achieve this. The way POCO classes are implemented, I can use persistent ignorant classes that can also directly be used with the EF data context. The added ability of T4 code generation allows me to generate those classes as well, so I don't have to code them by hand.

I am also very impressed with the implementation of model-first development in VS2010. VS2010 now has a model designer that you can use to create a database from. This allows you to use Visual Studio as a database modeling tool instead of relying on third-party modeling tools, which can be very expensive. While modeling in VS2010 doesn't cover every single option you can use when creating a database, combined with a good schema compare tool, it will allow you to simply create and maintain data models.

Out of all the ORM tools I have used in the past, I always find myself using EF. While version 1 had its shortcomings, it was still a good tool for interacting with databases. I have done several presentations on EF, and every session has been packed, which tells me that there is great interest in EF by the development community. I believe that EF4, with its new features, will be a first-class ORM tool and will continue to see greater use. If you haven't taken a good long look at EF, now is the time.