The Pragmatic DAL Architecture: Structure & Background
— The Data Access Layer (DAL) is a key component to working with big data.
Co-Authored by Bo Griffin
Users have data. Businesses have data. Our applications need data. The Data Access Layer (DAL) is a key component to working with that data. Since data is so important, we want to ensure that our DAL and application align well. This can make development much easier. An ideal pattern would align with the timeframe and constraints of the project.
In the first part of this series, we will cover the architectural structure and background related to the data access layer. In the next series of articles, we will review a few DAL patterns and the benefits of each.
Data heavy applications often use the three-layer architecture pattern. At the top, you have the Presentation layer. It is responsible for interacting with the all-important end-user.
In the middle is the “Application Service Layer”. This layer goes by many names. The other most common name is the Business Logic Layer (BLL). This layer may not actually have any business logic. Business logic is a concern that any layer may have. It could also be referred to as “Service Layer”; however, this could cause some confusion with “Web Services” or “Windows Services”. An “Application Service” is independent of its deployment container. It is possible to re-use an “Application Service” with multiple containers. The same functionality could be exposed with a Web API, WCF endpoint, ASP.NET MCV View, and so on.
On the bottom, the Data-Layer is responsible for persisting and retrieving data.
Within the 3-Layer architecture, data can have potentially many representations. These data representations are models. Each model has a different role to play. Which models are used vary by application. The figure below on the left shows which models exist and where they are used.
The ‘View Model’ contains data that is bound to a View. The View can also use the same or different ‘View Model’ to send data back to the application. The ‘Data Transfer Model’ aka ‘Data Transfer Object’ (DTO)’s role is to provide the contract between the Application Service and the Presentation Layer. The ‘Domain Model’ is an object that represents the intention of the application. The ‘Data Model’ is a representation of the application’s view over the database. The ‘Physical Model’ is the structure of data when it is persisted. This may seem like an excessive number of model types. Most applications do not need all of these representations. They can re-use a model at more than one layer. Between each layer of models, there is a mapping. The mapping is responsible for converting one model into another and back.
Change is necessary as an application grows. Making model changes to the bottom layers can often result in a cascade effect to all the layers above. The fewer model types an application has, the easier growth can be.
Data Layer Decomposed
At a high-level, a DAL’s primary responsibility is to enable communication to the persistence medium for the application. The figure to the right represents these responsibilities as sub-layers.
Starting at the lowest level, there is the Persistence Medium. This level actually stores the data. Often the Persistence Medium is a database. Next, the Data Access is a component that knows how to communicate to the Persistence Medium. This part handles calling the database to store and retrieve data. When the data comes out of the database, it may not be in a form that is directly useful to the application. The data needs to go through an Object Mapping that will convert the data in its raw form into something more palatable for the application. When dealing with ADO.NET, this amounts to converting a DataReader or Datatable into a strongly typed Data-Model class.
The Repository pattern provides a contract that isolates the application from having to deal with either the Object Mapping or Data Access. This isolation has a number of other benefits. The implementation can change to a different persistence technology, such as migrating from a relational to a NoSQL database. An application can scale out using a repository that manages writing to different backing databases. Unit-tests can use the interface to test against an in-memory collection or a XML file and bypass the database entirely. The repository is a natural fit for adding aspects such as caching, logging, auditing, and notifications.
The Data Access Layer (DAL) is key to handling data and it is important to ensure the DAL aligns well with the application. Ideal patterns align well with both the constraints and timeframe of the project. In our next article of the series, we will discuss data materialization and concurrency control.
Skip to The Decision MatrixView different options for DAL patterns within a decision matrix to help select the best options for your project by visiting the final article in this series: The Pragmatic DAL Architecture: Patterns & Decision Matrix.
Other Articles in this Series