Abstract Data Access Layer Design

The present document tries to describe the architecture of a specific layer of access to data for relational databases. This document tries to present/display a form to automate tasks of access to data.

Introduction

This article tries to describe the architecture for a specific data access layer for relational databases. The document tries to show a way to automate data access tasks.

Background

Below, I expose a series of definitions or concepts that will be needed to understand this document with clarity.

Data Provider

In this article, it should be understood that as a data provider, any kind of component that offers access to all data stored in a relational database is associated with a specific database management engine. Based on that definition, we will find data providers for Oracle, SQL Server, Microsoft Jet, MySQL and other engine types used for managing relational databases.

Data Access Tasks

A data access task will be defined as an abstraction for an operation to be performed in a database. Considering that, the tasks used to access all data will encapsulate the necessary information required for the successful operation execution, and this information will be independent of databases engines that we use. Some task samples for accessing data could be:

To insert a new record in a table

To update an existing record in a table

To eliminate a record in a table

To create a relation between two tables

Data Access Task Performers

It is another abstraction, its function is to execute the defined operations independently of the database engine used for the connection. Basically a component that inherits from this class will have to implement the way in which the tasks for their specific engine would be executed. A data access task performer would use a specific data provider for its implementation.

Script Builder

Again it consists of an abstraction that allows to generate standard SQL scripts using the stored information in the data access tasks objects. Each data task performer will be able to implement its own script builder or use the default script generator provided by this layer.

Class Diagram

Implementation for a Data Access Task Performer for the SqlServer Data Provider:

Use of Data Access Tasks

The data access task performer used will be defined by default using the connection string and the data type specified in a settings file. The data type specified should inherit from the DataTaskPerformer class and it could be in other assembly causing the model to be extensible.

Sample code for the Client class - The properties without attributes MapTo have the same names of the fields in the database.

Not Encrypted Dynamic Persistence

We say that it is dynamic since once the types are compiled, we can modify the destiny of the properties in an external file. It is not encrypted because the file is not encrypted. If it is required that it cannot be modified, an advanced end user must amount the file and pass the second parameter of the MappingFile attribute as true.

Sample code for a persistence definition file using dynamic persistence is not encrypted for the Client object. All properties with no attributes are called with their database column name in the target table. The fields without mapping must be defined with the attribute ignored as true.