The challenge of bringing data from efficient storage engines such as SQL Server into object-oriented programming models is hardly a new one. Most developers address this challenge by writing complex data access code to move data between their applications and the database. This requires an understanding of the database so that you can access data either from the raw tables, from views, or from stored procedures.
More often than not, databases are managed by DBAs whose job it is to ensure that the database is available, powerful, efficient, and secure. The means of accomplishing this generally take the data further out of the scope of your own concepts of how your data should be structured in your applications. It requires a solid knowledge of the database schema, table definitions, and stored procedures along with their parameters and results, views, keys, and more so that you can create your data access code.
Entity-relationship modeling, introduced in the 1970s by Peter Chen, goes a long way to solve this problem. Using entity-relationship modeling, programmers create a conceptual model of the data and write their data access code against that model, while an additional layer provides a bridge between the entity-relationship model and the actual data store. Most modeling, to date, gets done on a whiteboard.
With the ADO.NET Entity Framework, Microsoft has made entity-relationship modeling executable. They achieved this by a combination of XML schema files, behind the scenes code generation (creating .NET objects), and the ADO.NET Entity Framework APIs. The schema files are used to define a conceptual layer, to expose the data store’s (e.g., a SQL Server database) schema, and to create map between the two. The ADO.NET Entity Framework allows you to write your programs against classes that are generated from the conceptual schema. The Framework then takes care of all of the translations as you extract data from the database and send it back in.
Figure 1 shows the Entity Data Model’s layers, how they relate to one another, and where the model fits into your application.
Figure 1: How the different layers of the Entity Data Model fit into your application.
From DAL to a Foundation
The ADO.NET Entity Framework has a number of layers of abstraction. In its simplest form, you can use it as a data access layer complete with the ease of wizards and drag-and-drop controls. In its more complex form, the ADO.NET Entity Framework is truly a foundation for the future of data access in Microsoft’s Data Platform. A great example of this is to look at some of the projects that Microsoft is currently building based on the ADO.NET Entity Framework that were first presented at MIX07. One is currently codenamed “Astoria” and provides data through a specialized Web service. The service uses the Entity Data Model (EDM) to serve up a conceptual model of the data. Another project, code-named Jasper, uses the ADO.NET Entity Framework to build dynamic data layers with absolutely minimal effort on the end of the developer. By dynamic, this means that you build the data layer on the fly when you run the application and there is a lot of dynamic data binding, etc. Check the sidebars for links to more on these projects.
The point is that while the ADO.NET Entity Framework makes available APIs that developers can work with directly (the focus of this article), these APIs will also become building blocks for future development tools that Microsoft will provide down the road.
You can implement the ADO.NET Entity Framework in a range of scenarios, from using a default model with drag-and-drop data binding to constructing complex models to building services on top of the framework that you can use in a variety of ways.
In the rest of this article, you will see the simplest form of using the ADO.NET Entity Framework directly: drag-and-drop data binding against the default model. While this is a great entry point to understanding the ADO.NET Entity Framework, keep in mind that there are many layers exposed for developers to work with. You can access the model directly using Entity SQL or through the higher level Object Services API. The conceptual model is highly customizable, allowing you to do things such as inheritance or structure schemas that look very different than the data store upon which they depend.
http://www.code-magazine.com/article.aspx?quickid=0711051&page=1