Getting to Know the Entity Framework

After completing the chapter, you’ll be able to

• Define what an entity is and why it’s important.
• Specify the major elements of the Entity Framework.
• List and describe the files used to store Entity Framework information.
• Create a simple Entity Framework example.

When an architect wants to design a real-world building by creating a blueprint, one of the tools used to ensure the blueprint is accurate is a model. Often you see a model of the building as part of the presentation for that building. Models are helpful because they help others visualize the ideas that reside in the architect’s head. In addition, the models help the architect decide whether the plan is realistic. Likewise, software developers can rely on models as a means of understanding a software design, determining whether that design is realistic, and conveying that design to others. The Entity Framework provides the means to create various kinds of models that a developer can interact with in a number of ways. As with the architect’s model, the Entity Framework uses a graphical interface to make information about the underlying database structure easier to understand and modify.

The Entity Framework is actually a Microsoft ActiveX Data Object .NET (ADO.NET) technology extension. When you create the model of the database, you also make it possible for the Integrated Development Environment (IDE) to automatically create some of the code required to make the connection between an application and the database real. Because of the way ADO.NET and the Entity Framework interact, it’s possible to create extremely complex designs and then use those designs directly from your code in a way that the developer will understand. There isn’t any need to translate between the levels of abstraction—the Entity Framework performs that task for you.

Before you can begin using the Entity Framework to perform useful work, however, you need to know a little more about it. For one thing, you need to know why it’s called an Entity Framework. It’s also important to know how the various models work and how they’re stored on your system, should you ever need to access them directly. The following sections provide this information and more about the Entity Framework. You’ll then use the knowledge you’ve gained to create a very simple example. This example will help you better understand what the Entity Framework can do because you’ll actually use it to interact with a simple database.

Defining an entity

An entity is the data associated with a particular object when considered from the perspective of a particular application. For example, a customer object will include a customer’s name, address, telephone number, company name, and so on. The actual customer object may have more data than this associated with it, but from the perspective of this particular application, the customer object is complete by knowing these facts. If you want to understand this from the traditional perspective of a database administrator, the entity would be a single row in a view that contains all of the related information for the customer. It includes everything that the database physically stores in separate tables about that particular client. When thinking about entities, you need to consider these views of the data:

• Physical The tables, keys, indexes, views, and other constructions that hold and describe the data associated with a real-world object such as a customer. All of these elements are optimized to make it easier for the Database Management System (DBMS) to store and manipulate the data efficiently and reliably, without error. As such, a single customer data entry can appear in multiple tables and require the use of multiple keys to create a cohesive view of that customer. The physical storage of the data is efficient for the DBMS, but difficult for the developer to understand.
• Logical The combined elements required to define the data used with a single object, such as a client. From a database perspective, the logical view of the data is often encapsulated in a view. The view combines the data found within tables using keys and other database elements that describe the relationships and order required to re-create the customer successfully. Even so, the logical view of a database is still somewhat abstract and could cause problems for the developer, not to mention require a lot of code to manage successfully. ADO.NET does reduce the amount of coding the developer performs through the use of built-in objects, but the developer must still understand the underlying physical construction of that data.
• Conceptual The real-world view of the data as it applies to the object. When you view a customer, you see attributes that define the customer and remember items that describe the customer, such as the customer’s name. A conceptual view of the data presents information in this understandable manner—as objects where the focus is on the data, not on the structure of the underlying database.

When you want to think about customers as a group, you work with entities. Each entity is a single customer, and the customers as a group are entities as well. In order to visualize the data that comprises a customer, the Entity Framework relies on models. These models help the developer conceptualize the entities. In addition, the Entity Framework stores these models in XML format for use in automatically generating code to create objects based on the models. Working with objects makes life easier for the developer.

In times past, developers needed to consider the physical (tables), logical (views), and conceptual (data model) perspectives of data stored in a database. A developer had to know precisely which table stored a particular piece of data, how that table was related to other tables in the database, and how to relate the data in such a way as to create a complete picture of a particular entity. The developer then wrote code to make the connectivity between the application and the database work. The Entity Framework reduces the need to perform such tasks. A developer focuses on the entity, not the underlying physical or logical structure of the database that contains the data. As a result, the developer is more productive. Working with entities also makes the data easier to explain to others.

An entity contains properties. Just as objects are described by the properties they contain, entities contain individual properties that describe each data element. A customer’s last name would be a property of a customer entity. Just as classes have configurable getters and setters, so do properties in the Entity Framework. Every entity has a special property called the key property. The key property uniquely defines the entity in some way. An entity can have more than one key property, but it always has at least one. An entity can also group multiple properties together to create a complex type that mimics the use of user-defined types with standard classes.

It’s possible to create a relationship between two entities through an association. For example, you might create an association between a customer entity and the order entities associated with the customer. The association type defines the specifics of the association. In some respects, an association is similar to a database-level join. One or more properties in each entity, called association endpoints, define the relationship between the two entities. The properties can define both single and multicolumn connections between the two entities. The multiplicity of the association endpoints determines whether the association is one-to-one, one-to-many, or some other combination. The association is bidirectional, so entities have full access to each other. In addition, an entity association can exist even when the target data lacks any form of database-level join specification. All of the association instances used to define an association type make up what is called the association set.

In order to allow one entity to view the data provided by an associated entity, the entities have a navigation property. For example, a customer entity that’s associated with multiple order entities will have a navigation property that allows each order to know that it’s associated with that customer. Likewise, each order will have a navigation property that allows each customer entity to see all of the orders associated with it. The use of navigation properties allows your code to create a view of the entities from the perspective of a particular entity. When working with a customer entity, the application can gain access to all of the orders submitted by that customer. In some respects, this feature works much like a foreign key does in a database, but it’s easier to work with and faster to implement.

Some entities derive from other entities. For example, a customer can create an order. However, the order will eventually have a state that creates other entities, such as a past-due order entity or a delivered-order entity. These derived entities exist in the same container as the order entity as part of an entity set. You can view the relationship between entities and derived entities as being similar to a database and its views. The database contains all of the data, but a view looks at the data in a particular way. In the same way, a derived entity would help you create applications that view a particular entity type within the set of entities.

The final piece of information you need to know for now about entities concerns the entity container. In order to provide a convenient means to hold all of the entity information together, the Entity Framework employs the entity container. Before you can interact with an entity, your application creates an entity container instance. This instance is known as the context. Your application accesses the entities within a particular context.