由多个 DLL 使用的外部配置文件

发布于 2024-09-03 21:09:56 字数 234 浏览 3 评论 0原文

我有多个 DLL，用于将数据读/写到我的数据库中。

有一个表示层DLL和一个数据访问层DLL。我希望这些 DLL 共享一组连接字符串。

我的想法是将连接字符串存储在外部配置文件中的单独 DLL 中。我不确定这是否是一个好主意，以及是否可以在表示层和数据访问层中引用该外部 DLL。

另一个问题是我是否应该编写一个辅助类来从外部配置文件读取数据，或者是否应该使用内置的 .Net 方法？

谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

似最初 2024-09-10 21:09:56

将配置文件访问代码隔离在单独的类中。通过该类上的接口使配置数据（连接字符串等）可用。让接口存在于共享程序集中。让任何需要此接口的类通过依赖注入获取对配置类实例的引用。如果您尚未使用 DI 框架，我强烈推荐 Autofac。

你取得了什么成就？表示和数据访问类现在仅依赖于共享接口定义。他们不关心该接口的实现是什么，无论它是从 web.config、machine.config 还是其他存储中读取连接字符串。更好的是，您现在可以通过伪造实现来更轻松地测试您的类。

更新：首先，说明如何通过接口获取配置数据。假设我们有以下配置服务：

public interface IConfigurationService
{
    string ConnectionString {get;}
}

public class ConfigurationService : IConfigurationService
{
    string ConnectionString {get;}

    public ConfigurationService()
    {
        // load configuration
    }
}

我的数据访问类可以直接使用此类：

public class DataAccess
{
    private string _connectionString;

    public DataAccess()
    {
        var config = new ConfigurationService();
        _connectionString = config.ConnectionString;
    }
}

这种方法的问题是耦合。 DataAccess 现在直接依赖于 ConfigurationService 类。我们为 DataAccess 编写的任何测试都会无意中受到 ConfigurationService 类的影响。另外，如果我们需要切换 ConfigurationService 的实现，则需要更改 DataAccess （以及直接依赖于此类的所有其他类）。

为了解决这个问题，我们反转依赖层次结构并引用接口而不是具体的类，如下所示：

public class DataAccess
{
    private string _connectionString;

    public DataAccess(IConfigurationService configurationService)
    {
        _connectionString = configurationService.ConnectionString;
    }
}

数据访问类现在不知道配置服务实现是什么以及如何创建该实例。

Isolate the configuration file access code in a separate class. Make the configuration data (connectionstrings and whatnot) available via an interface on that class. Let the interface live in a shared assembly. Let any class that needs this interface get a reference to an instance of the configuration class via dependency injection. If you're not already using a DI framework I can highly recommend Autofac.

What have you achieved? Presentation and data access classes are now only dependent on a shared interface definition. They don't care what the implementation of that interface is, whether it reads connection strings from web.config, machine.config or some other store. Even better, you can now more easily test your classes by faking the implementation.

Update: First, to illustrate making the configuration data available via an interface. Say we have the following conffiguration service:

public interface IConfigurationService
{
    string ConnectionString {get;}
}

public class ConfigurationService : IConfigurationService
{
    string ConnectionString {get;}

    public ConfigurationService()
    {
        // load configuration
    }
}

My data access class could use this class directly:

public class DataAccess
{
    private string _connectionString;

    public DataAccess()
    {
        var config = new ConfigurationService();
        _connectionString = config.ConnectionString;
    }
}

The problem with this approach is coupling. DataAccess is now directly dependent on the ConfigurationService class. Any tests we write for DataAccess will inadvertently be affected by the ConfigurationService class. Also, should we need to switch out the implementation of ConfigurationService it would require changes to DataAccess (and all other classes directly dependent on this class).

To solve this, we invert the dependency hierarchy and references an interface instead of the concrete class, like this:

public class DataAccess
{
    private string _connectionString;

    public DataAccess(IConfigurationService configurationService)
    {
        _connectionString = configurationService.ConnectionString;
    }
}

The data access class is now oblivious as to what the configuration service implementation is and how that instance is created.

回复收藏 0 原文