Classic ASP has very rudimentary data access tools. You basically get ADO, a recordset object and thats about it. So I'm going to look at how you can turn these building blocks into an all purpose Data Access Layer.
Opinion: why is the Macbook Air a full 300 pounds (600 dollars) more expensive than in the US?
Data Access Layers in Classic ASP (Part 1)
What is a DAL
You hear the term Data Access Layer a lot when talking about building complex web applications in ASP.NET. But if you're working in Classic there doesn't seem to be much advice about. A Data Access Layer in the traditional sense of the term is a layer of code which acts as a gate-keeper to the database. All the database specific code and usually any code which derives a value from a simple calculation using values from the database is kept in the Data Access Layer (DAL for short). Simple validation can also be done in the DAL to help ensure that the database is kept consistent and clean.
ASP.NET has built up a variety of tools over the years to make the process of creating a DAL much easier and now its pretty much a drag and drop exercise, especially if you are using Microsoft products end-to-end. Classic ASP has been largely ignored is this regard so the developer is forced to build the DAL from scratch.
How Does a DAL typically work
ASP.NET and other technologies generally use what is called and Object Relational Mapping as a starting point for the DAL. What this means is that for every table in the database there is a class which represents the table structure and how the table relates to other tables. Each object instantiated from that class represents a row in the table. In that way an array of product objects can represent a table of product rows.
What does this gain you? Well essentially it means that you can give the database some intelligence about the data it's supposed to store. It can look at the data as it comes into the objects and make decisions about validation, data formatting, etc. It can derive more complex data from the data its given and store it without the business layer being cluttered. It can store statistics about how the data is accessed and stored. It can give you a more coherent picture about a group of related data fields without the developer having to worry about writing complex SQL statements. And along the same lines, a good DAL will abstract the database technology so any database system can be used with the application without affecting the other application layers (business logic, etc).
My own approach
When I built my DAL in Classic ASP I decided to take a different route and look at building a configurable Dynamic SQL module. This isn't really a DAL in the truest sense the word but is more flexible and can achieve many of the same things. The main goals of the project were to:
Abstract the mechanics of the database from the Business and presentation layers.
Format data coming out of the database in a configurable way
Format and validate data going into the database in a configurable way
Protect the database from SQL Injection attack
Provide a shorthand syntax for accessing related data across tables
Keep performance as fast as possible using sensible caching
Make it easy and pain free to configure
Automate processing of forms into the database with as little glue code as possible, where possible.
Provide sensible validation warnings and errors to the business and presentation code where possible.
Essentially the aim was to build a black box class which had public methods for creating records, updating records, updating fields in a record and deleting records. Each of these operations would be fully validated and the code would do its best to escape any nasty data before it got inserted into the database. In this way I could achieve the look and feel of a traditional DAL without the hassle of creating libraries of stub objects for every project I wanted to use it with.
In the next part
In the next part I'm going to look at how I approached the design of the DAL to meet the project goals. I'm also going to start to look at some of the implementation and issues that arose.
