N-Tier Applications and .NET: Achieving Isolation between DAL and BOL


In the previous two article (N-Tier Applications and .NET and N-Tier Applications and .NET: A Simple Example) I explained the concept behind N-tier applications and also gave you a simple example. This example builds on what we developed previously and illustrates how to achieve more isolation between the layers.

The limitation with "simple example"

In the last article we saw how to build a simple system with three layers DAL, BOL and UI. That works fairly well for small to intermediate systems. However, the problem with the approach is that there is still tight coupling between BOL and DAL. If you recollect in our BOL we embed SQL statements directly. That means tomorrow if you change any of your SQL query or stored procedure name you need to recompile BOL again. We can avoid the mixing of DAL and BOL responsibilities by making them more isolated. In order to achieve this isolation you can create more classes in DAL that do the job of encapsulating SQL statements and stored procedures. In this way BOL is never exposed to any internals of database schema such as table names and column names. If you change any of your queries or stored procedures BOL remains unaffected.

As per modified version our program flow becomes:

  1. UI talks with Customer BOL
  2. Customer BOL talks with Customer DAL
  3. Customer DAL talks with Database Helper
  4. Database Helper talks with database

Here, UI as well as BOL require to work with information such as CustomerID, CustomerName and so on. We encapsulate such information in a separate "state class" called CustomerState. In other words database column values (state of a Customer) are encapsulated in a separate state class having equivalent properties.

Sample Application

The sample application consists of three projects

  • NTierDemo
  • NTierDemo.BOL
  • NTierDemo.DAL
  • NTierDemo.StateClasses

The first project represents a presentation layer, the second and third layers represent business logic layer and data access layer respectively. Finally, state classes are inside NTierDemo.StateClasses project. For the sake of simplicity I have put a simple validation inside BOL class. In real life scenarios you will of course much complex processing or validations in BOL.

The sample consists of a simple web form that acts as a data entry screen for Customers table of Northwind database. The form allows to Insert, Update and Delete records to the Customers table.

Downloading and running the application

You can download the complete source code above (see top of this article).

Before you run the application at your end make sure that the web application project is marked as IIS application. Also, ensure that the database connection string is changed as per your requirements.

Next sample

We still have tight coupling between UI and database. This is due to the fact that our Select methods are returning DataSets which contain actual database column names. This means any change to database column names is going to affect UI layer. In the next article I will illustrate how we can avoid this tight coupling using collection classes.


Bipin Joshi is an independent software consultant and trainer by profession specializing in Microsoft web development technologies. Having embraced the Yoga way of life he is also a meditation teacher and spiritual guide to his students. He is a prolific author and writes regularly about software development and yoga on his websites. He is programming, meditating, writing, and teaching for over 27 years. To know more about his ASP.NET online courses go here. More details about his Kriya and Meditation online course are available here.

Posted On : 10 April 2005

Tags : ASP.NET Data Access Architecture Components