Kriya and Meditation for Software / IT Professionals. Conducted by Bipin Joshi in Thane. Read more...
Learn ASP.NET MVC, ASP.NET Core and ASP.NET Design Patterns from the comfort of your home. Online courses conducted by Bipin Joshi on weekends. Click here for more details.

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:

  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 a software consultant, an author and a yoga mentor having 22+ years of experience in software development. He also conducts online courses in ASP.NET MVC / Core and Design Patterns. He is a published author and has authored or co-authored books for Apress and Wrox press. Having embraced the Yoga way of life he also teaches Meditation and Mindfulness to interested individuals. To know more about him click here.

Get connected : Twitter  Facebook  Google+  LinkedIn

Posted On : 10 April 2005


Tags : ASP.NET Data Access Architecture Components