One of the necessary evils in enterprise application architecture is the relational database. Databases go back long time and are needed to persist data of applications. Relational databases are well-known and widely accepted as the way to persist data. These type of databases date back to the 1960s and are today well established. SQL is common language that most programmers are familiar with. When building enterprise applications the programmer who thinks in objects and their relationships must map the object model to this relational data structure. This is the topic of my latest lecture in my Design and implementation of software course, Lecture L08 Data Source Layer .
There are many well known challenges in working with databases. They tend to dominate design of applications and can become the main part of a system even though they should only persist data and most of the work is in the domain. Another problem with relational database in particular is that the object world and the relational world of tables and rows are quite different. This is what we call the impedance mismatch.
The most common way to organise programs to access the database is to create a new layer in the system, Data Source Layer, also called Persistence Layer. The idea is then to move the database code into a separate layer and away from the application domain. Very often the domain and the data model are similar so this might sound like a duplication of effort.
The simplest and most intuitive way is to create a gateway to each table (or set of tables). This is called Table Data Gateway which is similar to DAO pattern made famous in the Microsoft world. We can also have a gateway to each row, Row Data Gateway. This is useful when working with one row in a request for example, but it becomes a overkill if we need to work with many rows to have a class for each row. In cases where the domain model and the data model are independent, we can use a Data Mapper which is based on the mapper base pattern. It becomes the responsibility of the mapper to talk to both the domain model and the database. Finally, a simple way to work with a database is to have Active Record. The idea is that an Active Records contains all the fields in a database table and knows how to load itself and save itself.
See lecture:
Flickr cover image: orangejon
