Getting to Know the Entity Framework

Understanding the Entity Framework elements

The Entity Framework relies on XML files to perform its work. These files perform three tasks: defining the conceptual model, defining the storage model, and creating mappings between the models and the physical database. Even though the Entity Framework does a lot of the work for you, it’s still important to understand how these elements work together to create a better environment in which to write applications.

Now that you a have a little idea of what constitutes the Entity Framework elements, it’s time to discuss them in greater detail. In this case, we’re looking at the logical structure of the Entity Framework. The physical structure (the XML files and their content) is discussed in the “Introducing the Entity Framework files” section of the chapter. The following sections discuss the conceptual model, storage model, and model mappings.

Considering the conceptual model

The conceptual model is the part of the Entity Framework that developers interact with most. This model defines how the database looks from the application’s perspective. Of course, the application view must somehow match the physical realities of the underlying database, but there are many ways in which this happens. For example, a C# application will use an INT32 value, rather than the Structured Query Language (SQL) int type. The conceptual model will refer to the data type as INT32, but the reality is that the database itself stores the data as an int.

The conceptual model is also used to create the classes used to interact with the database. The Entity Framework manages the conceptual model. As you make changes to the conceptual model, the changes are reflected in both the classes that the Entity Framework creates for your application and in the structure of the database. In addition, the Entity Framework automatically tracks changes to the database design and incorporates them into your implementation classes. As a result, your application can always access the data and functionality included with the target database.

A conceptual model also incorporates the concept of a namespace, just as your applications do. An Entity Framework namespace performs the same functions as the namespace in your application. For example, it helps define entities with the same name as unique features. Using namespaces also helps group like entities together. For example, everything related to a customer can appear in the same namespace, making it easier to interact with the customer in every way needed.

At the heart of the conceptual model are the entity and association definitions used to create the view of the database. Each entity definition includes the information described in the “Defining an entity” section earlier in this chapter. When you use the designer to interact with the database model, what you’re really doing is modifying the XML entries that create and define each of these entity definitions. The XML entries are stored on disk and used to re-create the graphic appearance of the model when you reopen the project.

Considering the storage model

The storage model is the part of the Entity Framework that defines how the database looks from the database manager’s perspective. However, this model provides this view within Microsoft Visual Studio, and it provides support for the conceptual model. This model is often called the logical model because it provides a logical view of the database that ultimately translates into the physical database (see the “Defining an entity” section earlier in this chapter for a description of the various database views).

As with the conceptual model, the storage model consists of entity and association definitions. However, these definitions reflect the logical appearance of the actual database, rather than the presentation of the conceptual model within the application. In addition to the entity and association definitions, the storage model includes actual database data such as commands used to query the information within the database. You’ll also find stored procedures in this model. All of this additional information is used by ADO.NET to create connection and command objects automatically, so that you don’t have to hand-code the information as part of your application.

Considering the model mappings

At this point, you know that there are two models used with the Entity Framework—the conceptual model presents the application view of the database and the storage model presents the logical database manager view of the database. These two models are necessarily different. If they were the same, you wouldn’t need two models. The need for two models is also easy to understand once you consider that the application’s use of the database is always going to differ from the database manager’s goals of storing the data efficiency and reliably. In order to make the two models work together, the Entity Framework requires model mapping—a third element that describes how something in the conceptual model translates to the storage model, and vice versa.

The overall goal of the model-mapping part of the Entity Framework is to create a definition of how the entities, properties, and associations in the conceptual model translate to elements within the storage model. This mapping makes it possible for the application to create a connection to the database, modify its structure, manage data, and perform other tasks with a minimum of manually written code. Most of the code used to interact with the database is automatically generated for the developer using the combination of the conceptual model, storage model, and this mapping layer.