Database Reference
In-Depth Information
familiar ADO.NET objects, using
EntityConnection
and
EntityCommand
objects to return an
EntityDataReader
.
Understanding the Entity Data Model
The core of ADO.NET EF 3.5 is in its Entity Data Model. ADO.NET EF 3.5 supports a logical store model
that represents the relational schema from a database. A relational database often stores data in a
different format from what the application can use. This typically forces developers to retrieve the data
in the same structure as that contained in the database. Developers then often feed the data into
business entities that are more suited for handling business rules. ADO.NET EF 5.0 bridges this gap
between data models using mapping layers. There are three layers active in ADO.NET EF 5.0's model.
•
Conceptual layer
•
Mapping layer
•
Logical layer
These three layers allow data to be mapped from a relational database to a more object-oriented
business model. ADO.NET EF 3.5 defines these layers using XML files. These XML files provide a level of
abstraction so developers can program against the OO conceptual model instead of the traditional
relational data model.
The conceptual model is defined in an XML file using Conceptual Schema Definition Language
(CSDL). CSDL defines the entities and the relationships as the application's business layer knows them.
The logical model, which represents the database schema, is defined in an XML file using Store Schema
Definition Language (SSDL). The mapping layer, which is defined using Mapping Schema Language
(MSL), maps the other two layers. This mapping is what allows developers to code against the
conceptual model and have those instructions mapped into the logical model.
Working with the Entity Data Model
Most applications running today cannot exist without having a database at the back end. The
application and the database are highly dependent on each other; that is, they are tightly coupled, and
so it becomes so obvious that any change made either in the application or in the database will have a
huge impact on the other end; tight coupling is always two-way, and altering one side will require
changes to be in sync with the other side. If changes are not reflected properly, the application will not
function in the desired manner, and the system will break down.
Let's take a look at tight coupling by considering the following code segment, which you used in
Chapter 13 as part of Listing 13-3:
// Create connection
SqlConnection conn = new SqlConnection(@"
server = .\sql2012;
integrated security = true;
database = AdventureWorks");
// Create command
string sql = @"select Name,ProductNumber
from Production.Product";
SqlCommand cmd = new SqlCommand(sql, conn);
txtReader.AppendText("Command created and connected.\n\n");
