N-Tier Applications and .NET: Achieving Isolation between DAL and BOL
Introduction
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:
- UI talks with Customer BOL
- Customer BOL talks with Customer DAL
- Customer DAL talks with Database Helper
- 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.
