Asp.net DAL and BLL preferred design pattern approach

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").

Answer 2

Well, I'm gonna tell you about a few pitfalls with your approach, and how I generally do it.

Pitfalls

Your DAL-instance property seems like a smart, weird way of doing a singleton. You should remember that requests to your webserver can be handled asynchronously, so if your Activator.CreateInstance call will take some time, this could result in some problems.

Your BLL-layer suffers from the same problem, I guess. It's better to do this kind of initialization on the application startup event (can't remember the exact name).

What you are basically using here is the DI-principle and the repository pattern. Both are great, and will allow for modifications and testing, however, since your abstract class will be in the DAL and your BLL-methods will call the DAL-classes, your BLL needs to know about the DAL. This can be a problem. You could create an intermediate library with an interface to your abstract class instead.

What I typically do

I really don't like "layers" in an application, since it's often hard to distinguish between different types of functionality, and in which direction they should know about other layers. I use another approach, which I'm not really sure is dubbed anything, but I call it the dependency circle :) Basically, it's like a dart board, where the innermost assemblies will know nothing about the outermost.

In your typical blog-engine web-app, I'd do something like this:

BlogEngine.Core holds POCO-entities of various items (Post, User, Comment, whatever) and also various interfaces to services. These services can include IEmailService, IBlogRepository, IUserManagement, etc. etc... I now make a BlogEngine.Infrastructure.Persistence assembly, which knows about the .Core and implements IBlogRepository. I do the same for all other services.
Now - Your BlogEngine.Web only needs to reference your .Core assembly and an IoC-framework assembly that will take care of all your dependencies. If I want to update a post, I can do myIOC.GetInstance<IBlogRepository>().SaveOrUpdatePost(newPost);.
Let's say you want to notify authors when people post a comment on their blogs. You could implement this logic in .Core as an Notifier-class. This class could resolve the IEmailService and then send whichever email you need.

Point being: You got a core, which should never change with your domain. Then you got infrastructure assemblies which know only about Core. You got your web-app which know about Core and the IOC-framework - And you got your IOC which knows about everything, and is allowed to do so :) If you need to make changes, chances are that it's in the infrastructure assemblies and so you only need to update your IOC settings and implement which

I hope this makes sense, if not, please leave a comment and Ill try to explain further :)

Good luck

Answer 3

This is a good approach. I am using this approach too. I use enterprise library for DAL. recently I found that using of L2S is useful for DAL.

I recommend using of NHibernate too.