Driscoll Brian - Entity Framework 6 Recipes

Brian Driscoll 2013

Brian Driscoll 1, Nitin Gupta 1, Rob Vettor 1, Zeeshan Hirani 1 and Larry Tenny 1

(1)

Abstract

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

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.