A Complete Guide to Master Data Access Layer Efficiently

Enterprise database management systems generally include a number of outer layers, each with its own specific task. For example, the business logic layer, which encodes the real-world business rules that determine how data can be created, stored, and changed, accesses the data through the data access layer, which provides simplified access to the data.

This enables database administrators to isolate each supported dataset in the database, ensuring that only permitted users can access the stored data and that changes to one schema do not affect any of the other supported schemas.

Read on for a deeper dive into the data access layer: its importance, its architectural components, and how one is designed. We hope this gives you the information and confidence to apply this to your data infrastructure.

What is the data access layer?

The data access layer (DAL) sits between the business logic layer (BLL) and the data storage layer, creating an abstraction layer that manages the data storage and retrieval. The DAL enables the BLL to interact with the data storage system without knowing anything about its specific implementation.

The DAL accomplishes this by providing:

• Connection management: The DAL executes and manages all connections to local and cloud data storage systems, including handling errors and exceptions related to data access.
• Data abstraction: The DAL maps the data from the data storage system(s) to the application’s data objects and vice versa.
• Querying and data operations: The DAL generates and executes SQL queries or other data access commands that retrieve and store data, supporting transactions and other data access features.

The DAL is reusable. It is also completely independent of the business logic and data storage implementation. This enables it to be modified or extended easily without affecting the underlying data access code. Even better, since the BLL can’t “look through” the DAL to the data storage layer, no third-party application can access the entire database.

Depending on the specific requirements of the application and the data storage system in use, DALs can be implemented using a wide variety of data access technologies, such as ADO.NET, Java Database Connectivity (JDBC), object-relational mapping (ORM) libraries, or a data virtualization platform like CData Virtuality.

Why is layered access important?

The DAL plays a crucial role in safeguarding access to the database. It acts as a gateway between the application’s logic in the presentation layer and the underlying data storage. It transmits user input from the presentation layer, validating its semantics and authorization before passing it to the BLL.

The layered nature of this access also provides several architectural benefits to both database managers and application developers:

• It provides a layer of abstraction such that a developer working in the BLL does not need to worry about how the data is stored or know anything about the nature of their operations to create, read, update, and delete data (aka CRUD operations).
• It can support multiple databases, so the application can make use of any database as required.
• It segregates the data access code, promoting better maintainability and easy migration of the database.
• It enhances system scalability by providing a centralized location for making calls to the database(s). This makes it easier to scale database access as the data storage layer changes and makes the application itself easier to configure and maintain.

Real-world example

In an airline ticket reservation system, when a user attempts to view the flight availability from the front end, the BLL sends the query request to the DAL. The DAL retrieves the required data from one or more locations from the storage system(s) and sends it back to the BLL.

The BLL does not need to care about where the DAL retrieves the data or how the data is represented at the data storage layer. It just converts the data into a format the user can understand and then sends it to the front end.

Data access layer architecture

DAL architecture is made up of three major components:

Data access logic components abstract the logic necessary to access the underlying data stores. Using data access logic components encourages the access functionality to be more centralized. This, in turn, makes the application easier to configure and maintain.

Data helpers facilitate data access, transformation, and manipulation within the DAL. The helpers are constructed from dedicated procedures and libraries designed to increase data access efficiency while not relying too heavily on service agents and local component layers.

Service agents are code that manages the semantics of communicating with an external service. Service agents isolate your application from the necessity to call diverse (and possibly changing) services. They can also provide additional services, such as basic mapping between the format of the data the service exposes and the format your application requires.

How to design a data access layer in 5 steps

Scope out the requirements for the DAL

Create an overall design for your data access layer:

1. Identify your data source requirements.
2. Determine your data access approach.
3. Choose how to map data structures to the data source.
4. Investigate the best way to connect to the data source.
5. Determine strategies for handling data source errors.

Design the DAL components

1. Identify all the data sources that you will access.
2. Decide how to access each data source.
3. Determine whether you will need helper components, or if they are just desirable for simplifying the development and maintenance of data access components.
4. Investigate design patterns that may be helpful, such as Table Data Gateway, Query Object, Repository, etc.

Design the data helper components

1. Identify functionality that could be moved out of the data access components and centralized for reuse.
2. Research available helper component libraries.
3. Consider custom helper components for common problems such as connection strings, data source authentication, monitoring, and exception processing.
4. Consider implementing routines for data access monitoring and testing in your helper components.
5. Consider the setup and implementation of logging for your helper components.

Design the service agents

1. Use the appropriate tool to add a service reference. This will generate a proxy and the data classes that represent the data contract from the service.
2. Determine how the service will be used in your application. For most applications, you should use an abstraction layer between the business layer and the data access layer, which will provide a consistent interface regardless of the data source. However, in smaller applications, it might make more sense for the business layer, or even the presentation layer, to access the service agent directly.

Analyze other considerations

Manageability

Creating a data access layer that’s easy to install, configure, and monitor makes life much easier for administrators and operators. It also makes it easier to detect, validate, resolve, and verify errors at run time. You should always strive to maximize manageability when designing your application.

Performance

Performance is a function of both your data layer design and your database design. Consider both together when tuning your system for maximum data throughput.

Security

The data layer should protect the database against attacks that try to steal or corrupt data. It should allow only as much access to the various parts of the data source as is required. The data layer should also protect the mechanisms used to gain access to the data source.

Deployment

When deploying a data access layer, the goal of a software architect is to consider the performance and security issues in the production environment.

Consider locating the data access layer on the same tier as the business layer to improve application performance. If you need to support a remote data access layer, consider using the TCP protocol to improve performance.

Finally, do not locate the data access layer on the same server as the database.

CData Virtuality: An enterprise-level data access layer

With support for multiple integration styles, over 200 connectors, and SaaS deployment options, CData Virtuality provides a data access layer that is built especially for heavy enterprise workloads. Users gain instant, platform-agnostic access to data sources, metadata tools, and data consumers; your database management team gains an agile architecture that can scale at lightning speed whenever data requirements change.