Question

I am developing a couple of small ASP.NET application and would like to know what pattern. approach do you use in your projects.

My projects involve databases, using Data access and Business logic layers.

The data-access approach that I was using so far is the following(I read in some book and liked it):

For DAL layer:
Creating an abstract class that will define all database manipulation methods to implement.
The abstract class will contain a static “Instance” property, that will load (if instance == null) an instance (Activator.CreateInstance) of the needed type (a class that implements it).

Creating a classes that implement this abstract class, the implementation will be according to the databases (SQL, mySQL and etc) in use.
With this I can create different implementation according to database in use.

For BLL layer:
A class that encapsulates all all retrieved fields , and static methods that will call the DAL classes.

Is it a good approach?
What do you prefer to use in those situations?

Answer 1

By using static class methods, you’re hiding dependencies on these components and limiting your options in the future (you can’t subclass your business layer, for example).

Instead of using singletons and static methods for your data access and business layers, consider changing your business layer class to require a data access instance, and keep a single instance of the business layer in your top level application:

public class Global HttpApplication {

    // This would really be a property
    // It's also unfortunate this has to be static, but you're stuck with
    // default constructors for ASP.NET pages, so there's no alternative.
    public static BusinessLayerClass BusinessLayer;

    protected void Application_Start(object sender, EventArgs e) {
         AbstractDataAccessLayer dataAccess = new ConcreteDataAccessLayer();
         Global.BusinessLayer = new BusinessLayerClass(dataAccess);             
    }
}

Pages then use it like this:

public void PerformSomeBusinessFunction() {
    Global.BusinessLayer.DoSomething();
}

This makes it obvious that your business layer requires data access, provides a convenient place to specify which type of data access object it will use, and paves the way for you to use different creational strategies if they become necessary. For example, you might supply a data access factory instead of sharing a single instance across all your business layers.

The general principle here is called “dependency injection” (sometimes it’s referred to as “inversion of control”, which is the even-more general principle behind DI.)

If this dependency injection by hand starts to get cumbersome, consider using a dependency injection framework (people also call these “IoC containers”).