Database Reference
In-Depth Information
Chapter 1
Getting Started with Entity Framework
When working with relational databases, we think in terms of tables with rows and columns. Tables are highly
structured and excel at set-based processing. Before the wide adoption of object-oriented programming, we thought
about problems “procedurally” and solved them by writing code in a structured, top-down manner, function after
function. Both worlds lined up well: Tables, rows, and columns closely matched the structured and procedural
patterns in our code. Life was good - for a time ...
Much has evolved on the code side. We now think in terms of objects and domain models. We architect,
design, and program against real-world things, like customers and orders. We draw nouns in our problem space
on whiteboards. We draw lines between them, denoting relationships and interactions. We build specifications
and assign work to development teams in terms of these drawings. In short, we architect, design, and program at a
conceptual level that is very distant from the logical and physical organization of the database.
While the software development process has dramatically matured and the way in which we reason and
solve problems has evolved, the database has not. The data remains locked in the same tables, rows, and columns
paradigm, where it has been for many years. Unfortunately, this creates a mismatch (an impedance mismatch , as
Microsoft fellow Anders Hejlsberg might call it): Object-oriented class hierarchies vs. a highly normalized database
structure.
To cope with this gap, software projects often introduce a “database layer” that translates application domain
classes into the rows and columns saved in tables. This approach has spawned many commercial and open-source
data access frameworks; all attempting to bridge the ever widening gap between evolving development processes and
structured data. Interestingly, an entire new field of Object Relational Mapping (ORM) has come out it.
The Entity Framework, coupled with the Language-Integrated Query (LINQ) framework, both from Microsoft,
enables us to address the mismatch problem head-on. Using Entity Framework, we model entity classes for our
application on a design surface or directly in code. Then we model relationships ( associations ) between these entities.
In our code, we construct LINQ queries to program against these entities and associations. LINQ allows us to express
relational database set concepts directly into our code while working in terms of entity types and associations. All
of this helps to streamline our development experience while reducing the overall effort. Instead of coding large
numbers of highly redundant ADO.NET data access constructs, we express our data needs in simple LINQ queries.
Instead of programming against the schema of a highly normalized database, we code against entity classes. Entity
Framework maps entity classes to the underlying database for you.
We use the term entity class or entity object to refer to a class that typically represents a domain item in an
application. Domain classes represent real-world objects, such as an Employee, Department, or Manager, which your
application will represent and track. The end users and stakeholders of your application should be able to look at the
domain classes in your application and say, “Yes, that's what our business does.” Entity classes define the schema ,
or properties, but not the behavior, of a domain class. In essence, entity classes expose the state of an object.
Note
 
 
Search WWH ::




Custom Search