Question

我已在单独的项目中使用公共图层设置我的VS解决方案：演示文稿，业务，实体和数据访问层。我在DAL中有这个静态类AppSettings，我想在Globla.asax.cs中的Load()调用它的Application_Start方法。它基本上从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
        }
    }
 ...

Answer 1

我建议总是通过业务逻辑层来访问数据层，以便构建到业务逻辑层中的所有安全措施都在发挥作用。您是否希望在没有业务层的情况下使用数据层？

Answer 2

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

如果您专注于应用程序设计，那么您将专注于对您的应用程序有意义的设计模式，甚至是应用程序的各个部分。

了解模式是知识。知道何时何时不使用它们就是智慧......

这是一个人的意见，但我希望它有所帮助......

Answer 3

Ayende最近发表了一些反对这种做法的文章（我理解为这样）：

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

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

因此，如果您在获取数据时没有业务操作，则直接处理您的数据层！

Answer 4

如果数据在应用程序的配置文件（web.config）中，除了System.ConfigurationManager.AppSettings

之外，您不需要“通过”任何内容

Answer 5

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

即使在较小的应用程序中，我也会提倡为每个图层定义不同的设置对象。在我的设计中，它与你的BLLAppSettings类似。它将封装设置的源，在本例中是您的全局AppSettings类。但是，我的设计不同之处在于BLLAppSettings将是BLL层中定义的接口的具体实例，必须通过构造函数，工厂或依赖注入将其提供给BLL层。在我推荐的设计中，类似的类DALAppSettings是必要的。

通过这种方式，您的BLL和DAL不会耦合到表示层中定义的全局AppSettings。 BLLAppSettings和DALAppSettings的实现细节可以在必要时独立变化，但暂时可以保持内部绑定到您的全局AppSettings类。

始终遍历业务层以进入数据层？

5 个答案: