CHAPTER 1
■
INTRODUCING THE ADO.NET 4.0 ENTITY FRAMEWORK
4
• SPRINT.net: An open-source application framework, and based on the Java
version of Spring Framework, allowing you to build components that can be
integrated into multiple tiers of your application.
While this list is by no means complete, it is provided to illustrate the necessity and need for good
ERM application development products that remove many of the complexities of working with
databases to help improve productivity.
The ADO.NET Entity Framework does not have the same limitations of other modeling products.
This is because the Entity Framework works at a conceptual level that is based on the ERM and, as such,
provides a depth and richness of functionality that many of the stand-alone ERMs and UMLs cannot
provide.
As the name suggests, the Entity Framework allows you to work directly with Entities that represent
your own schema without having to deal with the nuances of DataReader and DataSet objects. Some
developers who have worked with or have some knowledge about Entity Framework compare it to other
relational mappers and try to classify it as an object relational mapper. This comparison or thought
process is not entirely correct. The Entity Framework does have relational mapping capabilities. But the
Entity Framework is much more than just a relational mapper, and the ORM capabilities it does have are
implemented much differently than that of other ORM products.
So, What Is the Entity Framework?
The Entity Framework is a set of technologies in ADO.NET that helps fill in the space between object-
oriented development (objects) and databases. This gap is commonly known as an “impedance
mismatch” and it exists because the mapping and organization of classes does not quite match up to the
organization of relational objects. Many mapping solutions have tried to solve this problem by mapping
OO (object-oriented) classes and properties straight to tables and columns.
For example, let’s use the case of customers and products. First, in a simple mapping scenario, you
may have a product class that contains a property that references an instance of a customer class.
Second, a customer class might contain a property containing a collection of instances of the product
class. While this might seem fine, how do you represent the foreign keys between customer and product
in the first case (while in the second case you have a reference of an object-oriented collection of
product instances that has no comparable column in the customer table in the database)?
A scenario such as this one is known as the conceptual space and is accomplished by raising the
abstraction level to a point that lets developers query entities and relationships in the conceptual model,
all while letting the Entity Framework translate the query operations to data source–specific commands.
It allows applications to be written against conceptual models and not directly against the database. By
doing so, the gap between object-oriented programming and databases has been closed, letting
developers focus on the task of developing applications, without concerning themselves about the
database (structure or otherwise) or data access.
You should start to see where the gap comes into play, simply because there is no one-to-one
mapping. Relationships between relational objects are represented much differently from class
relationships. And this is where the Entity Framework takes a much different approach. The EF maps
relational objects to conceptual models. Conceptual mapping provides a number of huge benefits. For
example, it provides the needed improved flexibility in creating (defining) and enhancing the logical
model.
■ Note The Entity Framework divides the data model into three separate models: conceptual, logical, and
physical. Each of these will be discussed in detail in Chapter 3.