Data Access Patterns: the Features of the Main Data Access Patterns Applied in Software Industry
Introduction
The data access is practically an indispensable aspect in all kinds of applications, it does not matter the volume and the type of the managed data by the software, data access is always present and this aspect must be implemented aiming to keep the software components with the maximum cohesion and the minimum coupling than possible, to have a high quality software scalable and non-dependent database application. The objective of this article is to give a overview of the main software data access patterns used in the software development industry, showing their features.
Aiming to implement the access for the data managed by applications it have been designed a lot of patterns, they being the main the following:
Table Data Gateway
Row Data Gateway
Data Mapper
Active Record
Repository
Data Access Object (DAO)
Each pattern has its own features and they are explained in the next sections.
Table Data Gateway
In the Table Data Gateway pattern, the main feature is a class which is responsible for encapsulate the access for the database table, the business model object interacts with the table data gateway to store and retrieve data from database. The Table Data Gateway is the pattern used by some frameworks such as the PHP framework Zend Framework.
Only one instance of the Table Data Gateway class can manage the data of all business model object instances of a specific type. The structure of the Table Data Gateway follows the scheme:
When it has been created it was thought to relational databases, but its structure allows it to be implemented with non-relational databases (NoSQL).
Row Data Gateway
In the Row Data Gateway pattern, the main feature is the class row data gateway that is responsible to manage the data access of only one business model object instance, each instance of row data gateway represents the data of one business model object instance. The Row Data Gateway is responsible only for to manage the store of data, so to retrieve data from database is used a class named finder, that is responsible to do the necessary queries on the database. The structure of the Row Data Gateway is represented on the following diagram:
The interaction of data row gateway class must be very simple, without any business logic.
Active Record
The main feature of the Active Record pattern is the business model object is responsible to manage its own interaction with database. Summarizing, in this pattern it looks like a business model object, a row data gateway and a finder class fused into a single class, but in this pattern the data access can have business logic. The diagram to represent this pattern is:
The Active Record is very popular in the MVC frameworks, some examples of frameworks, which use Active Record pattern are the Ruby framework Ruby on Rails, the Python framework Django, the PHP framework Laravel, and many others.
Data Mapper
In the Data Mapper pattern the main feature is the data mapper class, that is responsible to recognize business model objects and then store and load them from database, decoupling the business model objects from the database, the relationship between the classes involving this pattern is represented by the following diagram:
Currently, the Data Mapper pattern is very popular, being used in many data access frameworks such as the Java framework Hibernate, the .Net framework NHibernate, and the PHP framework Doctrine. It is a common thing the Data Mapper class uses metadata about the business model classes, often stored in XML files, class annotations, or mapper classes, to help it to know how to store and load the objects directly from database.
Repository
In the Repository pattern there is a repository class that is responsible to store and load data of business model objects in database, but with the main feature of to treat the interaction with database like an interaction with a object list. The following diagram represents the relationships involving the Repository pattern:
Currently the Repository pattern is a very common pattern in the software industry, because the low level of coupling it brings between the business model objects and database. Nearly always, there is the use of a data mapper behind the interaction of the repository class with database, making the repository responsible for only interactions with business logic features. The Repository pattern is a pattern encouraged by Domain Driven Design (DDD), because it is business focused.
Data Access Object (DAO)
The DAO patten many times is confused with others patterns which cover data persistence, mainly with the Data Mapper and Repository patterns, but these others patterns work with management of business model objects, and the DAO has as the main feature to work with management of the data transfer objects (DTO). The DAO class must store and load DTOs from database, and not business model objects. The following diagram show the relationship between the classes involved in the DAO pattern:
As the DAO is responsible to store and load DTOs from database, it is common in the web architecture, because with it is possible retrieve only the important data for the web client from the database, improving the software performance.
Conclusion
There are many patterns to deal with the data of object-oriented software in database, but there is not just one right way to do it, all depends of the type of software to be built. Looking for the explained patterns the Table Data Gateway uses only one intance to manage the data of all business model object instances of a same type, storing and retrieving the data from database; in the Row Data Gateway an instance of object manages the data of only one business model object instance, there being a separate class to restore data from database; Active Record puts data the access inside the business model object; in the Data Mapper a mapper takes care of how to store and load business model objects of database; and in the DAO the DTOs are stored and load, and not business model objects.
To choose a data access pattern to use it is necessary to look mainly the disponible tools, the size of software to be build, the desired performance, the time disponible to build the software, and how it is wished deal with data access, but nothing prevents to use more than a one pattern if necessary, for example, it is possible to use Repository with Data Mapper behind of it to deal with business model objects, and DAO to retrieve DTOs directly from database aiming performance when necessary.
References
Ermittelbar, E.N. (2013), Core J2EE Patterns, Prentice Hall.
Fowler, M. (2015), Patterns of Enterprise Application Architecture, Boston, Addison-Wesley.
