The leading authority on Entity Framework outside of the team at Microsoft that built it is, in my experience, Julie Lerman. Julie has been speaking at conferences on the topic since I first heard of Entity Framework, and she even wrote the book, literally, on this topic.
As the author of the highly acclaimed “Programming Entity Framework,” she agreed to discuss the technology with me. To get our conversation going, I opened with a question designed to be a bit provocative to someone who has embraced the technology: “If you like ADO.NET and bending the back-end schema to your desires is not a problem, then isn’t Entity Framework just another layer you don’t need?”
Julie said, “Entity Framework does much more than just add another layer into your data access. By providing a conceptual model for your developers to work against and removing the need to have to interact directly with the database, have an understanding of its schema, and constantly reshape database results back into domain classes, they can focus on programming against the domain and not the database.”
This is at the heart of it, the promise of the object-relational mapping nature of Entity Framework. We exchange an abstraction level for higher productivity and less complexity for the user (which in this case is the programmer). This strategy has served us well repeatedly in computer science as evidenced by the fact that writing code in machine language has been out of vogue for a long time. But we should never accept an abstraction layer lightly, and to justify this abstraction, we must look a bit at how things work under the covers.
There are a lot of moving parts to make this technology work. On one side we have the Relational Schema that will be familiar as it represents the way the data is represented on the back-end relational database. The Entity Data Model is the representation of the data as a collection that enables the developer to ignore the intricacies of how the data lines up in the database tables. For example, if we have a Customer concept in our project, then it is likely that the data about any given customer is spread across several tables, including order information, base customer data and contact details.
The Entity draws all of this data together into an Entity Object that abstracts these complications and handles the mapping of each field behind the scenes. The balance between doing things for you and letting you override the automated elements of the wizard is key and works well in Visual Studio 2010.
I have always said that there are two kinds of wizards: the good kind and the evil kind. The good wizards let you change what they do after the fact, while the evil ones keep the code they generate hidden and unattainable.
How you get to the Entity Objects is not proscriptive. As Julie pointed out, “Entity Framework is flexible enough to satisfy a variety of approaches. If you have a legacy database, you can build a conceptual model from that and then reshape that model to align with domain classes without losing the Entity Framework mappings back to the database. Entity Framework lets developers leverage existing stored procedures and views, or take full advantage of its query and command building capabilities.”
There are, in fact, currently three approaches to creating Entity Data Models, including Database First, Model First and Code First. Model First and Code First seem at first glance to be ways to approach a “green field” project where the database is not already established, but they can be used even when the database does already exist. It is just not used as the starting point for creating the Entity objects.
I personally prefer Database First as relational design helps me sort things out, but Code First as the newest approach is where all the attention seems to be these days since most developers are quite happy to not delve into the relational model. The original release of Entity Framework with Visual Studio 2008 (Entity Framework 1.0) supported only the Database First approach.
The Code First approach is the most recent, but appears to be fast becoming the most popular. When asked why this is the case, Julie replied, “For developers who do not want to worry about another model, Code First gives the best of both worlds, allowing you to map your domain classes to the database. Regardless of the back-end database, developers only need to learn one query syntax, namely LINQ to Entities, with the option of working at the more raw level of Entity SQL.”
I remain unconvinced about Code First (formerly called Code Only) as a superior approach because it is new and somewhat against my instincts as a relational database wrangler. Expect a lot of attention to follow on this particular approach, but I would say that the jury is still out for me on whether this is truly the best way to go for most projects.
