始终遍历业务层以到达数据层

本文关键字：数据 遍历 业务 | 更新日期: 2023-09-27 18:21:25

我已经在不同的项目中使用公共层设置了VS解决方案：Presentation、Business、Entitys和Data Access layers。我在DAL中有一个静态类AppSettings，我想在Globla.asax.cs的Application_Start中调用它的Load()方法。它基本上是从web.config加载我的应用程序设置。

我的问题是：我应该创建一个业务逻辑类来从我的表示层访问它，还是可以直接从表示层访问我的AppSettings到DataAccess层（忽略业务层）。

如果是这样的话，所有事情都是一样的吗？我必须始终通过业务层才能到达数据层吗？

public static class AppSettings
{
    public static int ApplicationID { get; set; }
    public static string ServiceEndpoint { get; set; }
    public static string ServiceCode { get; set; }
    public static string ConnectionString { get; set; }
    public static void Load()
    {
        //Connection String
        AppSettings.ConnectionString = System.Configuration.ConfigurationManager.ConnectionStrings["USpace"].ConnectionString;
        //Applicatin Settings
        AppSettings.ApplicationID = Convert.ToInt32(System.Configuration.ConfigurationManager.AppSettings["AppID"]);
        AppSettings.ServiceEndpoint = (string)System.Configuration.ConfigurationManager.AppSettings["ServiceEndpoint"];
        AppSettings.ServiceCode = (string)System.Configuration.ConfigurationManager.AppSettings["ServiceCode"];
    }
}

如果我必须通过业务逻辑层，BLL的类会是这样的？：

public static class BLLAppSettings
{
    public static int ApplicationID
    {
        get
        {
            AppSettings.ApplicationID
        }
    }
 ...

始终遍历业务层以到达数据层

我建议始终通过业务逻辑层访问数据层，以便在业务逻辑层中构建的所有保护措施都能发挥作用。您希望在没有业务层的情况下使用数据层吗？

如果你的重点是设计模式，那么无论如何，在小圆孔中敲击那些方形钉子都很有趣。

如果你的重点是应用程序设计，那么你就要关注对你的应用程序有意义的设计模式，甚至是应用程序的各个部分。

知道模式就是知识。知道什么时候使用它们，什么时候不使用它们是智慧。。。

这是一个人的指责，但我希望它能帮助。。。

Ayende最近发表了几篇反对这种做法的文章（我是这样理解的）：

http://ayende.com/blog/153061/northwind-starter-kit-review-it-is-all-about-the-services

我同意他的观点：你必须问问自己"这一层的目的是什么"，如果你不能回答，那么你就不能删除这一层并保持你的软件简单。

所以，如果你在获取数据时没有业务操作，那么直接处理你的数据层！

如果数据在应用程序的配置文件（web.config）中，则不需要"浏览"除System.ConfigurationManager.AppSettings 之外的任何内容

您应该从保持简单但合理开始。在设计应用程序时，软件工程的一般原则应该是您的指南。在这种情况下，我的直接想法是，通过拥有一个全局AppSettings类，您将把您的业务和数据访问层耦合到该类。现在这似乎是合理的，但当你有50种不同的设置，而其中只有20种应用于数据访问层时呢？如果以后，您的业务层必须从不同于DAL的来源加载设置，该怎么办？最重要的是，在您当前的设计中，您将两个层耦合到全局单例。这通常不是一个好主意。

即使在较小的应用程序中，我也主张为每个层定义不同的设置对象。在我的设计中，它将类似于您的BLLAppSettings。它将封装设置的源，在本例中是您的全局AppSettings类。然而，我的设计不同之处在于，BLLAppSettings将是在BLL层中定义的接口的具体实例，必须通过Constructor、Factory或Dependency Injection将其提供给BLL层。在我推荐的设计中，类似的类DALPettings是必要的。

这样，您的BLL和DAL就不会耦合到Presentation Layer中定义的全局AppSettings。BLLAppSettings和DALAppSettings的实现细节可以在必要时独立变化，但暂时可以在内部与全局AppSettings类保持联系。

相关文章：