Mapping – Taking the Horror Out of Data Access
Horror stories and the object data divide
Let’s face it, the world is getting more and more OO, but we are still
pretty happy with our relational databases. In fact the RDBMS is the foundation
upon which basically all of our data driven applications reside. Having said
this we are pretty aware of the fact that the relational data models we deploy
are limited. Sometimes they aren’t much more than a bunch of tables that
are increasingly cursed due to limitations and design flaws.
To develop great applications, we
need a solid foundation based on a great data model, a data model that should
matches real life as closely as possible, the so called domain model. How many
database schemas actually resemble the real-world problem? Data access has become
a time-consuming horror story that can take the fun out of any development project.
But it doesn’t have to be this way.
Benefits of OO in stateless business methods
Even though relational theory is great for storing and retrieving large
amounts of structured data, it hardly makes for readable business methods. The
reason being that the relational data model contains very little information
(despite what the name implies) about the relationships and intended use of
the data. It has a low level of abstraction in the same way as C compared to
VisualBasic. A properly implemented object-oriented data model on the other
hand gives you the full picture and allows business methods to contain more
straightforward, readable, code. Comparing two code snippets proves our point.
The first code snippet interfaces the relational data model through SQL, the
second interfaces the object-oriented data model through OO-notation (in this
example we use the API of an O/R DAL generated by Pragmatier
Data Tier Builder, se reference at the end of this article):
Public Sub GiveRaise(ByVal ConnStr As String, _