Asp.net DAL 和 BLL 首选设计模式方法

Question

我正在开发几个小型 ASP.NET 应用程序，想知道是什么模式。您在项目中使用的方法。

我的项目涉及数据库，使用数据访问和业务逻辑层。

到目前为止我使用的数据访问方法如下(我读过一些书并且喜欢它):

对于 DAL 层:
创建一个抽象类来定义要实现的所有数据库操作方法。 抽象类将包含一个静态“Instance”属性，它将加载(如果instance == null)所需类型的实例(Activator.CreateInstance)(实现它的类)。

创建一个实现这个抽象类的类，实现将根据所使用的数据库(SQL、mySQL等)进行。
这样我就可以根据使用的数据库创建不同的实现。

对于 BLL 层:
封装所有检索到的字段的类，以及将调用 DAL 类的静态方法。

这是一个好方法吗？
在这些情况下您更喜欢使用什么？

Answer 1

通过使用静态类方法，您可以隐藏对这些组件的依赖关系并限制您将来的选择(例如，您无法子类化您的业务层)。

不要对数据访问和业务层使用单例和静态方法，而是考虑更改业务层类以需要数据访问实例，并在顶级应用程序中保留业务层的单个实例:

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);             
    }
}

页面然后像这样使用它:

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

这清楚地表明您的业务层需要数据访问，提供了一个方便的位置来指定它将使用哪种类型的数据访问对象，并为您在必要时使用不同的创建策略铺平了道路。例如，您可以提供数据访问工厂，而不是在所有业务层之间共享单个实例。

这里的一般原则称为“dependency injection”(有时也称为“控制反转”，这是 DI 背后更一般的原则。)

如果这个dependency injection by hand开始变得麻烦，考虑使用 a dependency injection framework (人们也称这些为“IoC 容器”)。