What is a DAL?

Data Access Layer

Layered application architecture

A Data Access Layer or "DAL" is just one part of a layered or tiered application architecture. A layered or tiered architecture is essentially just a set of guidelines. It's goal is to help you structure and organise your application source code. One of the main reasons for using a layered approach is to deal with complexity. As applications become larger and more complex, we have to find ways to deal with this complexity.

A layered architecture breaks the application code down into a number of distinct layers or tiers. Each one of these layers is treated as a distinct and self contained component, helping to separate out and logically group the source code. A Data Access Layer deals with storing and retrieving data in a database. Generally speaking, a Data Access Layer would contain all the code that deals with the database.

The advantages of a Data Access Layer

Whether or not you choose to implement other layers, isolating data access code into a separate component has many advantages.

Maintainability

Keeping all the data access code in one place can make it easier to change. Changing code that is spread out throughout an application can be difficult and error prone. There are also opportunities to organise and document the code in a way that would not be easy otherwise.

Code re-use / framework

Keeping the data access code together can make it a lot easier to identify duplicate or similar code that can be consolidated, simplified or generalised. Usually, a standardised code framework can be created within the DAL to simplify and reduce the data access code.

Consistency and Standardisation

Data access code is usually very repetitive and there is often a lot of it. Keeping it all together makes it easier to keep the code consistent in terms of code layout, functional implementation, variable naming and code documentation.

Plug-ability

Isolating the implementation of the data access from the rest of the application has the knock on effect of making it easier to swap out. If you needed to provide the user with the option to store data in an MS Jet database or a SQL Server database then a DAL can expose a single interface and hide the implementation from the rest of the application. The rest of the application doesn't necessarily need to know whether it's dealing with SQL Server or MS Jet.

Sharing

You may find that other applications need to access your database. This is one of those situations where you often end up duplicating code across different applications. By keeping all the data access code together in a DAL component, it can be shared across applications. Taken to the next level, adding a web service interface would allow any application to access the database via your DAL.

Testing

Isolating the data access functionality gives you the potential to test it in a way that may have been impossible before. The DAL can be tested in isolation from the rest of the application. Either through your own test app or via an automated test tool such as NUnit.

ODS and the Data Access Layer

We've already mentioned data access code is repetitive and that there is often a lot of it. This is the kind of code that is perfectly suited to be automatically generated. ODS allows you to leverage the benefits of a DAL without actually having to write it yourself. ODS takes the automation to the next level by automatically designing and maintaining the database as well.