ADO.NET Entity Framework

ADO.NET Entity Framework is Microsoft's step towards its Data Platform Vision. In this blog, I am going to talk about the architecture of the ADO.NET Entity Framework and the way it will change application development style. Though it is in Beta Phase right now but is expected to be part of Visual Studio 2008 during mid of year 2008.

The Vision:

If we closely look at the new development initiatives from Microsoft, we can clearly see where Microsoft Development Platform is heading towards. Be it the new "language features" in C# 3.0 like LINQ or new "components" in framework like Communication Foundation, Workflow Foundation or the new features in "products" like Biztalk, SQL Server etc., one thing is common in all of them: "Abstraction". By the term abstraction I mean hiding all the complex details and exposing simple interfaces to achieve one goal of allowing the developers to concentrate on "what" do they need rather than "how" do they need.

Take example of LINQ. Simply put, the primary aim of LINQ is to develop a common querying language within the programming language so that developer does not have to learn new querying languages (like SQL, XPath etc.) varying on the kind of data source they are dealing with. Today with LINQ, you don't need to know SQL or XPath to search data from a database or XML data source. You just need to know LINQ and search every data source with it.

Now look at the structure of a typical query expression in LINQ. You will find the structure similar to SQL having keywords like "Select", "From", "Where" etc. along with a fleet of operators to work with. It is typically the smell of any 4GL language. SQL is a 4th Generation Language, similarly LINQ is a 4th Generation Language. And what is a 4th Generation language in anyway? Any construct that offers me the ability to specify "what" without asking me "how" is a 4th Generation language.

Take another example of WCF. You can now create generic services in WCF within no time that can work on REST principle (REST is like backbone of today's web) and that can also work on a completely proprietary protocols with very little efforts. In WCF we call them "Service" which is as generic as we have "object" type in any OO Programming Language. The same service can behave as a web service, can use message queues, can use TCP with just simple changes in configuration. Developer does not have to worry about intrinsic details. In fact whenever I personally design an architecture for Microsoft Partners, I either think of WCF or Biztalk whenever communication comes into picture. These two technologies are key to enable communication framework within software components as well as enabling integration between different disparate systems.

The examples can go on and on since the technologies offered by Microsoft are many. But the point that I am trying to make is that Microsoft has this vision to introduce abstraction to such an extent that things become extremely simple and we can produce great software within no time, no cost.

With ADO.NET Entity Framework, the Microsoft vision remains the same: To abstract data access with programmers so that they spend their time in writing "what" rather than "how". Imagine if the 4GL concept spans across all layers, application development will be over in the requirement gathering phase itself since the moment we specified 'what" do we need from application, application is ready. ADO.NET Entity Framework is a little step towards that vision.

Introduction:

A typical application has those 3 layers: Presentation, Business and Data Access. ADO.NET Entity framework will change the way Data Access layer is written. One way of looking at it is to consider as an ORM (Object Relational Modelling) framework. Any ORM framework aims to bridge the gap between the way data is represented in database (or better data source) and the way it is represented inside the application. An ORM framework does that by providing a framework that does the mapping between your classes and properties within it with database tables and their columns. This framework is an extra layer between the data access layer and data source. So developer do not have to write code against database, fetch data in some format, convert it to fit with objects in application and then use the data. Instead, developers do all their modifications on objects only and the changes are translated by the ORM framework into appropriate database calls. ADO.NET Entity Framework is also an ORM framework that provides this functionality. ORM frameworks are not new concepts, we have plenty of them (like nHibernate) in market. But what is different with ADO.NET Entity Framework is that it is much more than simply an ORM framework. Not only does it bridges gap between representation of data within application and database, but also it aims to improve upon performance (unlike other ORM frameworks that hits to performance) and more importantly it integrates with the programming language itself (we have LINQ to entities for the same reason) making this integration more flawless and easy to use.

Architecture:

I would take the picture (shown below) from one of the "data points" column of MSDN Magazine that clearly shows the high level developer architecture of ADO.NET Entity Framework. Let us dissect each element to appreciate the architecture better.

 

Entity Framework Layers (Logical + Mapping + Conceptual):

The three entity framework layers shown in above diagram are the core of whole functionality. These layers are also called as EDM (Entity Data Model). Entity framework engine basically takes decisions on the basis of the EDM. The first step that we have to do in order to use the entity framework is to generate (optionally edit based on requirements) these application specific layers. But do not worry, generating these layers (EDM) is not more than a matter of clicks. You can generate an EDM using a database as a starting point. You can then modify the XML manually (or possibly using a modelling tool that may be available in a future release of Visual Studio). When you add an ADO.NET EDM to your project, the wizard walks you through the process of creating the EDM.

The Logical layer contains the entire database schema in XML format. This represents the story at database side.

The Conceptual Layer is again an XML file that defines the entities (your custom business objects) and the relationships (the custom ones) that your application knows. So if you say that each Customer can have many associated orders, that relationship is defined in the conceptual layer even if this relationship does not exist at database side.

The Mapping layer is also an XML file that maps the entities and relationships defined at conceptual layer with the actual relationships and tables defined at logical layer. This is the core of entire Entity Framework that bridges the gap.

Within application we always interact with Conceptual layer. To talk to Conceptual Layer we can use

• A new language called Entity SQL directly (actually Entity SQL queries are fired using Entity Client provider which is very similar to ADO.NET model).
• LINQ to Entities, which is again another language integrated querying facility.
• Using Object Services which in turn uses an ObjectQuery Object.

Whenever we commit changes (like invoking SaveChanges() method) to databases from application, appropriate queries are fired (it also takes care of the relationships). We don’t have to think about relationships at application level since all the mapping is done at EDM layers. So, Entity Framework handles Relationships quiet neatly.

Wrapping UP:

The best wrap up that I can write is what John Papa gave in his article:

"The Entity Framework allows developers to focus on the data through an object model instead of the logical/relational data model. Once the EDM is designed and mapped to a relational store, the objects can be interacted with using a variety of techniques including EntityClient, ObjectServices, and LINQ.

While the traditional objects such as the DataSet, DataAdapter, DbConnection, and DbCommand are still supported in the upcoming release of ADO.NET available in Visual Studio "Orcas," the Entity Framework brings major additions that open ADO.NET to new and exciting possibilities."

There are other Microsoft initiatives in the data platform vision like having a framework to expose data as service and tools for developing for an occasionally connected architecture. More on those initiative in my future blog entries once I get my hands dirty with them as I have done with Entity Framework :).

 

Rahul's

Technorati Tags: ADO.NET Entity Framework Architecture,LINQ to Entities

Comments

• Anonymous
  March 28, 2008
  Thanks for such a nice post, keep it up Thanks and regards Pradeep www.ZoomPune.com

• Anonymous
  May 27, 2008
  ADO.NET Entity Framework is Microsoft's step towards its Data Platform Vision. In this blog, I am going to talk about the architecture of the ADO.NET Entity Framework and the way it will change application development style. Though it is in Beta Phas

• Anonymous
  June 05, 2008
  ADO.NET Entity Framework is Microsoft's step towards its Data Platform Vision. In this blog, I am going to talk about the architecture of the ADO.NET Entity Framework and the way it will change application development style. Though it is in Beta Phas

• Anonymous
  July 29, 2008
  We are using “LINQ to SQL classes” in V.S 2008 as the application data layer, my question is can “LINQ to SQL classes” be upgraded to “Entity Data Model”, or should we create a new EDM XML file?

• Anonymous
  July 30, 2008
  I am not sure what do you mean by upgrading LINQ to SQL to entity data model. LINQ to SQL is tightly integrated with the data source (SQL Server). If you say that you want to treat LINQ to SQL classes like entities, you might be interested in using TableAttribute. http://msdn.microsoft.com/en-us/library/system.data.linq.mapping.tableattribute.aspx

• Anonymous
  March 24, 2009
  I found a great article about Entity Framework disconected/layered and I want to share with yours: http://www.codeproject.com/KB/architecture/attachobjectgraph.aspx

• Anonymous
  October 02, 2009
  Very nice article.  Thanks for the nice post and keep up the good work.

• Anonymous
  March 01, 2013
  Hi Rahul, Great post.. good information Thanks for sharing your thoughts.