所以让我首先说“我知道这不是最佳实践”并且我不想想要将 app.config 文件中的信息添加到 web.config 文件中......我已经一个项目本身就是一个类库,它也会使用很多类库。
通常在我的单元测试项目(用于测试)或我的 Web 项目(在生产中使用库)中,我必须添加所有配置信息。这些库的调用方式不会因每个项目而异,因此我正在寻找一种方法来让调用项目读取被调用项目的配置文件。
我在网上查了一下,到目前为止我发现的唯一两件事是:
别这样做。您需要将信息添加到调用项目的配置文件中
你不应该这样做,但我知道怎么做(不包括如何:/)
我已经用“正确”的方式做了一段时间,这给我留下了很多 web.config 和测试项目配置文件,其中包含从类 lib app.config 文件复制的信息。我确实认为这样做有一个特定的、合理的用例。
据我所知,最佳实践是避免库中的类(甚至一般类)对 app.config/web.config 的直接依赖。这并不意味着您不使用app.config。这意味着您的班级不知道他们正在使用它。 例如,
public class MyClassThatDependsOnSomeSettings
{
private readonly ISettings _settings;
public MyClassThatDependsOnSomeSettings(ISettings settings)
{
_settings = settings;
}
public void DoSomething()
{
var settingA = _settings.SettingA;
}
}
public interface ISettings
{
int SettingA {get;}
string SettingB {get;}
}
现在您可以考虑
MyClassThatDependsOnSomeSettings
完成了。它不需要对 .config 文件进行任何访问。它只需要一个实现
ISettings
的实例。 那个可以从.config中读取。
public class SettingsFromConfiguration : ISettings
{
public int SettingA
{
get
{
string setting = ConfigurationManager.AppSettings["settingA"];
int value = 0;
int.TryParse(setting, out value);
return value;
}
}
public string SettingB
{
get { return ConfigurationManager.AppSettings["settingB"];}
}
}
看起来这只是移动物体并做同样的事情吗?确实如此,几乎如此。最大的区别是,虽然您可以使用从 app.config 读取的
ISettings
实现,但您也可以编写其他实现。您可以编写一个使用硬编码值的代码,您可以编写自定义配置部分而不是使用
AppSettings
,或者如果您将来有一个带有 JSON 配置文件的应用程序,而没有 AppSettings
,您的类仍然可以工作。 这应用了依赖倒置
,这意味着类应该依赖于抽象(如接口)而不是具体的实现。 在构造函数中放入
ISettings
的要求称为
依赖注入,具体来说是构造函数注入。