he 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. However, writing such code 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 toward solving 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 using a combination of XML schema files, behind the scenes code generation (creating .NET objects), and the ADO.NET Entity Framework APIs. The schema files define a conceptual layer to expose the data store's (e.g., a SQL Server database) schema, and to create a map between that and your application-level objects. The ADO.NET Entity Framework allows you to write your programs against classes that are generated from this conceptual layer. The Framework then handles all the required translation as you extract data from the database and send it back in.

Figure 1: How the different layers of the Entity Data Model fit into your application.

This article provides an explanation of the basic concepts of ADO.NET Entity Framework, gives you an opportunity to get your hands dirty with code, and provides a glimpse into the possibilities that ADO.NET Entity Framework opens up for developers.

Figure 1 shows the Entity Data Model's (EDM's) layers, how they relate to one another, and where the model fits 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 easy-to-use 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 Resources sidebar 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 exposed layers 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.

Editor's Note: This article was first published in the Nov/Dec 2007 issue of CoDe Magazine, and is reprinted here by permission.