The ADO.NET Entity Framework at 10,000 Feet The ADO.NET Entity Framework is an ORM (Object Relational Mapping) tool and is Microsoft’s main data access strategy moving forward. Microsoft released version 1 with Visual Studio 2008 SP1 with the .NET Framework 3.5 SP1. They released version 4 with Visual Studio 2010 and the .NET Framework version 4. The product team decided to sync the version number with the version of the .NET Framework. You may see references to v1 as Entity Framework v3.5 as well as v1 to reflect this.

ORM tools allow you to work with your relational database in a way that makes more sense to you as a developer and doesn’t require you to hand code SQL (which is something I don’t think many developers ever actually want to do on a regular basis). You work with a set of objects in your application that represent the database and an ORM tool will generate dynamic SQL that is sent to the database and executed. I have heard it said that ORM tools have an 80/20 use ratio, meaning that on average an ORM tool will solve 80% of your database access issues and the other 20% will likely need to be done with stored procedures or some other method. I think this is a solid ratio, but the ratio tends to be more like 95/5 for me. The real ratio will ultimately depend on the type of applications that you write. For quite a few of the projects I work on, the Entity Framework solves 100% of my data access problems. On average, I would say that just by using an ORM, my data access development time is cut by at least 75%. Since the ORM tool handles all of my CRUD (Create Read Update Delete) operations, I don’t have to write and debug SQL code for basic data access. This is, of course, the beauty of ORM in general and the Entity Framework fills this space nicely.

I have used many ORM tools over my development career and have personally found the Entity Framework to be my favorite and the one I use by choice in all new applications. I found v1 to be very usable (despite what others may think) and have several applications currently in production using it. There is no denying, however, that v4 is a game changer and as a developer, you should take a few minutes to check it out. I don’t think there is anything wrong with the other ORM tools out there and they are certainly viable tools for doing the job, I just prefer Entity Framework.

Entity Framework uses LINQ (Language INtegrated Query) and Entity SQL to query, but you will likely be using LINQ primarily. Entity SQL can fill some nice gaps where your query is a little too complex for LINQ but can give you another option before going to a stored procedure. I use a combination of full LINQ queries and lambda functions depending on the need, but my tendency is more towards lambdas. Entity Framework gives you the ability to easy navigate between relations using Navigation Properties so I rarely need to write joins in LINQ. This ultimately leads to cleaner code and more maintainable code, which is why I think it is a good fit with building ASP.NET MVC applications.

Entity Framework 4 introduced several new features that made working with ASP.NET MVC easier and cleaner. One of the really nice things about the fact that you have greater separation of concerns easier with ASP.NET MVC is that unit testing is infinitely easier. While you could technically unit test Entity Framework v1, v4 makes it much easier to do since mocking is easier. This is all accomplished by using my favorite feature of Entity Framework v4 - the POCO support. POCO (Plain Old Clr Object) allows you build a persistent ignorant data access layer, which is by nature better for testing. Without POCO, the classes you would work with are objects derived from actual Entity Framework classes. Using the Entity Framework classes makes mocking more difficult and thus testing is more difficult. The classes also carry a dependency on the Entity Framework so you would have to reference the System.Data.Entity assembly whenever you use them. While this is not a major issue, it does make things like Dependency Injection more difficult. POCO solves this by giving you classes that are completely independent of the Entity Framework. POCO thus allows for easy use of Dependency Injection and other patterns for building modular applications. For example, later in the article I’ll show you how to implement the Repository and Unit of Work patterns. Both made easier with POCO due to Entity Framework v4.