Entity Framework 4.0 Recipes
structured and amenable to all sorts of interesting set theory. Before the dawn of object-oriented programming, back in the day when we focused on “structured” programming and wrote function after function, it seemed a good idea to break down a big problem into lots of little problems. Working with
tables, rows, and columns seemed a good match with our code. Our code was structured and procedural. Our data was structured and backed up by database side procedures. Things lined up well. Many database vendors even supplied preprocessors that allowed developers to intermix SQL statements and C (or Fortran) code. Life was good for a time.
Much has evolved on the code side. Now we think in terms of objects in a domain model. We architect, design, and program against real-world things like customers and orders. We draw the nouns in our problem space on whiteboards. We draw lines between them, denoting relationships and interactions between customers and orders. 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 organization of the database.
While the software development process has matured, and the way in which we reason about and solve problems during the process has evolved, the data in our databases has been locked in the same tables, rows, and columns structure. The synergy between structured data and our code evaporated as quickly as structured programming in the heat of modern object-oriented development.
To cope with this growing mismatch, many projects introduced a “database layer” to isolate the object-oriented code from the data store. This layer translated objects to the rows and columns saved in tables. Many commercial solutions were introduced, including an entire field of Object Relational Mapping (ORM). These tools provided many out-of-the-box yet configurable ways to bridge the ever-widening gap between the evolving development process and structured data.
structured and amenable to all sorts of interesting set theory. Before the dawn of object-orientedprogramming, back in the day when we focused on “structured” programming and wrote function afterfunction, it seemed a good idea to break down a big problem into lots of little problems. Working withtables, rows, and columns seemed a good match with our code. Our code was structured andprocedural. Our data was structured and backed up by database side procedures. Things lined up well.Many database vendors even supplied preprocessors that allowed developers to intermix SQLstatements and C (or Fortran) code. Life was good for a time.Much has evolved on the code side. Now we think in terms of objects in a domain model. Wearchitect, design, and program against real-world things like customers and orders. We draw the nounsin our problem space on whiteboards. We draw lines between them, denoting relationships andinteractions between customers and orders. We build specifications and assign work to developmentteams in terms of these drawings. In short, we architect, design, and program at a conceptual level that isvery distant from the logical organization of the database.While the software development process has matured, and the way in which we reason about andsolve problems during the process has evolved, the data in our databases has been locked in the sametables, rows, and columns structure. The synergy between structured data and our code evaporated asquickly as structured programming in the heat of modern object-oriented development. To cope withthis growing mismatch, many projects introduced a “database layer” to isolate the object-oriented codefrom the data store. This layer translated objects to the rows and columns saved in tables. Manycommercial solutions were introduced, including an entire field of Object Relational Mapping (ORM).These tools provided many out-of-the-box yet configurable ways to bridge the ever-widening gapbetween the evolving development process and structured data.
