Creating ADO.NET Entity Data Models

Over the past few years, data access in .NET Framework applications has been transformed. The introduction of the Entity Framework into ADO.NET means that you can use conceptual models of your normalised data, without worrying about the structure of that data in your data store. You simply define the entities that you require in your application and then map them to the underlying data by using an Entity Data Model (EDM). Sounds complex, but by using the Entity Data Model tools in Visual Studio, it's just a case of following a wizard and then a little click & drag. I'll start by looking at how to create a model from an existing database and in the next post I'll show you some of the cooler features of the tools.

If I add a new ADO.NET Entity Data Model item to a project, Visual Studio automatically launches the Entity Data Model Wizard to step through the creation of an EDM. The first decision to make is whether to generate an EDM from an existing database or create an empty model. I'll choose the first option for this post.

After selecting or creating a connection to the AdventureWorks database, I can select the database objects that I want to use in my application. I'll simply choose a few tables for now, but you can also create entities from views and stored procedures.

When I click Finish, Visual Studio creates an EDM with an entity per table that I selected and associations between the entities corresponding to the relationships defined in the database.

If I right-click in the designer pane and click Mapping Details, I can view the mappings between an entity in my EDM and the underlying table in the database.

And if I close the designer pane and then right-click the model in Solution Explorer, I can select to open it in an XML editor to see the XML code behind the mappings.

When Visual Studio generates the model and mappings, it also auto-generates an object layer based on the contents of the model.

I can code against these objects and their properties to work with and navigate around the data in the model.

As you can see, no more complex Transact-SQL join query strings risking run-time errors if my table or field names aren't accurate, just simple coding against a conceptual model that maps to my data. These few lines of code populate a data grid with SQL Server data based on the contents of a combo box on a form.

You can create an EDM for many different types of data source, so it makes it easier to update applications if your data store changes. You simply change the connection information for the model, update your mappings, and your code should continue to run without any modifications. If you also configure your application to store the model data externally (use the Metadata Artifact Processing property of the model), you only need to redeploy the three model definition files, not the entire application.

So you've now seen how quick and easy it is to generate a model from an existing database and write code against in. In my next post, I'll show you more features of the Entity Designer and EDMs.