Asp.net DAL and BLL preferred design pattern approach

Question

I am developing a couple of small ASP.NET applications and would like to know which template. the approach that you use in your projects.

My projects include databases using data access layers and business logic.

The approach to data access that I have used so far is the following (I read in a book and liked it):

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

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

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

Is this a good approach?
What do you prefer to use in such situations?

Answer 1

Using static class methods, you hide dependencies on these components and limit your possibilities in the future (for example, you cannot subclass your business level).

Instead of using singletones and static methods to access data and business layers, consider changing the business layer class to the required instance of data access and save one instance of the business layer in your top-level application:

public class Global HttpApplication { // This would really be a property // It also unfortunate this has to be static, but you're stuck with // default constructors for ASP.NET pages, so there 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 as follows:

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

This makes it obvious that your business layer requires access to data, provides a convenient place to specify what type of data access object it will use, and paves the way for using various creation strategies if necessary. For example, you can provide access to factory data instead of sharing a single instance across all business layers.

The general principle here is called “ dependency injection ” (sometimes referred to as “control inversion”, which is an even more general principle for DI.)

If this dependency injection manually starts cumbersome, consider using the dependency injection framework (people also call these “IoC containers”).

Answer 2

Well, I will tell you some pitfalls with your approach and how I usually do it.

Traps

The property of a DAL instance seems like a smart, weird way to make a singleton. You must remember that requests to your web server can be processed asynchronously, so if your Activator.CreateInstance call takes some time, this can lead to some problems.

Your BLL layer suffers from the same problem, I think. It’s better to do this initialization at application startup (I don’t remember the exact name).

You mainly use the DI principle and the repository pattern. Both of these are excellent, and will allow you to modify and test, however, since your abstract class will be in DAL, and your BLL methods will call DAL classes, your BLL should know about DAL. This can be a problem. Instead, you can create an intermediate library with an interface to your abstract class.

What do i usually do

I really do not like the “layers” in the application, as it is often difficult to distinguish between different types of functionality and in which direction they should know about other layers. I use a different approach, which I'm really not sure that something is duplicated, but I call it a circle of dependencies :) In principle, this is like darts, where the most hidden assemblies do not know anything about the external.

In my regular web blog application, I would do something like this:

BlogEngine.Core contains POCO objects of various elements ( Post , User , Comment , whatever), as well as various interfaces to services. These services may include IEmailService , IBlogRepository , IUserManagement , etc. Etc. Etc. Now I am creating a BlogEngine.Infrastructure.Persistence assembly that knows about .Core and implements IBlogRepository . I do the same for all other services. Now, your BlogEngine.Web should only reference your .Core assembly and IoC-framework assembly, which will take care of all your dependencies. If I want to update the message, I can do myIOC.GetInstance<IBlogRepository>().SaveOrUpdatePost(newPost); .
Let's say you want to notify authors when people post comments on their blogs. You can implement this logic in .Core as a Notifier class. This class can enable the IEmailService, and then send any email address you need.

Point: you have a kernel that should never change with your domain. Then you got the infrastructure builds that only know about Core. You have your web application that knows about Core and IOC-framework. And you got your IOC, who knows everything, and he is allowed to do this. If you need to make changes, there is a chance that this is in the infrastructure assemblies and therefore you only need to update the IOC settings and implement which

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

Good luck.

Answer 3

This is a good approach. I also use this approach. I am using the corporate library for DAL. I recently discovered that using L2S ​​is useful for DAL.

I also recommend using NHibernate.