The .NET Framework has made the software developer’s life quite a bit easier, and nowhere is this more apparent than database access. It may have taken Microsoft a few iterations, but with ADO.NET and its ease of implementation and detached architecture, I think Microsoft finally hit the mark. In this article, I will focus on how to implement the code for a simplified database tier for a multitiered content management system (CMS) based on my simplified interpretation of the new proposed .NET architecture specifications by Microsoft. (I’ll assume that you know the basics of ADO.NET.)

Microsoft’s database tier architecture specification
Just to save you time in reading the long documents provided by Microsoft, this is what they say to include in the database tier: CRUD and data logic functions.

For those of you who don’t know it, CRUD stands for create, read, update, and delete. If you think about it from a programming point of view, that’s all that is needed from the database. The basic idea presented by the proposed .NET architecture is to let the database do what it does best: handle the creation, maintenance, and retrieval of persistent data. Many databases out there are overworked because they have business logic pushed onto them. When you restrict the database tier to CRUD, the business logic is put back where it belongs—in the business logic tier.

Figure A shows the basic architecture of the database tier.

Figure A
Basic architecture of database tier

That’s all. If you’re including more than this, you’re placing too much in this tier. I think you all know what a database is, but what is this thing called the data access logic component (DALC)?

A DALC is typically a single class that encapsulates the data logic and CRUD functions for a single table or group of related tables in a database. Notice that this definition allows for some small degree of data logic beyond CRUD. DALC allows for more specific data reads, updates, and deletes as opposed to blindly reading the entire database into the business logic tier and working with the data there.

There are many approaches to designing and building DALCs. Two common methods are using a combination of scalar values and data sets as a means to interact with the business logic tier, and using a business entity (BE).

The scalar value method
Listing A shows an example of a DALC using scalars and data sets for the simplified cmsContent table. (I described a more detailed version of this table in my previous article.) As you can see, it’s only a constructor: a create, a read, an update, and a delete method. Other than the constructor to instantiate the class, these methods are each performing a CRUD function. If I were to include the DALC for the other tables in the CMS database, you would see that they all mirror this same pattern.

Notice that the approach uses as parameters the scalar values equivalent to the columns found in the database. They also have the same names, but this isn’t a requirement—though this will probably be the case, since it makes it easier to understand the mapping between the DALC and the database.

Only the read method returns data to the business logic tier, and it does so in the form of a generic data set. It is up to the logic of the business logic tier to process the data within the data set. This approach truly performs only CRUD functionality. You would implement this approach like this:
 
static void Main(string[] args){
// Create a ContentDALC object
ContentDALC DALC = new ContentDALC();
// Get Content for ID 1234
DataSet ds = DALC.Read(1234);
Console.WriteLine(“Content Body: {0}”,
ds.Tables[“Content”].Rows[0][“Body”]);
}
 

The business entity method
The second approach mentions a business entity. Microsoft defines multiple ways of implementing a business entity. In the case of a CMS, I use this definition: A business entity is an object-oriented class that represents a single row in a table or view of a database. Sounds a lot like a DALC, doesn’t it? The big difference is that this is a business logic tier object; it doesn’t actually interact directly with the database.

Let’s take a look at a BE. As you can see in Listing B (for this example, I used the simplified cmsContent table again), this is a rather simplified version of a BE because it doesn’t do much in the way of validating and has a limited number of properties and methods. But it gets the idea across. The BE contains three constructors. The first is the default; the second takes the table key as a parameter (used for reading and deleting); and the third takes all columns of the table (used in creating and updating). The BE contains a method to simplify its being populated by the DALC. Finally, it has a bunch of properties that represent all the columns of the table so that they can be created, read, and updated.

Listing C shows how the DALC has been changed to work with the BE. Really, as far as the DALC is concerned, passing the BE just simplifies its parameter list. On the other hand, for the developer trying to work with the data associated with this DALC, things are a bit easier and safer because now the table can be manipulated like an object, like this:
static void Main(string[] args) {
// Create a ContentDALC object
ContentDALC DALC = new ContentDALC();
// Create a ContentBE
ContentBE BE = new ContentBE(1234);
// Get Content for ID 1234
DALC.Read(BE);
Console.WriteLine(“Content Body: {0}”, BE.Body);
}
 

Two approaches
You now have two approaches for getting access to your data. And, if you look at the architecture documents provided by Microsoft, you’ll find numerous other approaches. Which approach you use is up to you. Microsoft’s architecture documentation should help you choose the correct one for your development purposes.