使用静态类来促进对设置的访问是否可以接受？ [英] Is using a static class to facilitate access to appsettings acceptable?

问题描述

我的应用程序的app.config文件中有一些密钥，其中包含电子邮件设置。我目前正在为工作而开发的应用程序有几个地方需要发送电子邮件（主要是进行错误检查以使我们知道发生了什么不好的事情）。为了更轻松地在我需要的地方获取该设置（而不是返回到app.config来查找要在 ConfigurationManager.AppSettings [ SomeKey]。ToString（）中使用的文本字符串） / code>我创建了一个简单的静态类，以容纳一些返回我需要的值的只读属性。这是基本结构

I have some keys in the app.config file of my application that house email settings. The application I am currently developing for work has several places where I need to send off an email (mostly in error checking to let us know something bad happened). To make it easier to grab that setting where I need it (instead of going back to the app.config to look up the text string to use in ConfigurationManager.AppSettings["SomeKey"].ToString() I created a simple static class to house a few readonly properties that return the values I need. Here's the basic structure

internal static Class myClass
{
    internal static string setting1
    {
        get { return ConfigurationManager.AppSettings["SomeKey"].ToString(); }
    }
    internal static string setting2
    {
        get { return ConfigurationManager.AppSettings["SomeOtherKey"].ToString(); }
    }
}

我这样做的方式是否可以接受？我找不到与此相关的问题，但不禁以为我缺少一些东西。

Is the way I am doing this acceptable? I can't find an issue with this but can't help thinking I'm missing something.

其他信息：

我知道简单地使用设置的方法。
我无法使用设置。设置文件是由于我在工作的地方制定了代码政策而定，这将使我的工作方式变得不必要。

I am aware of the method of simply using the Settings.Settings file. I can't use the Settings.Settings file due to the code policy in place where I work, which would make the way I'm doing this unnecessary.

编辑：
通过可接受我的意思是通常这样做还是认为是个好主意？我意识到整个社区都无法推测我的工作是否可以接受。

By "acceptable" I mean is it commonly done or considered a good idea? I realize the community at large cannot speculate on acceptability at my job.

推荐答案

这还不错，但是如果花费一点点钱就可以变得更好调整。 （好吧，也许不是真的很小。）

It's not bad but it can be better with a small tweak. (Ok, maybe not real small.)

如果您的类依赖于静态类，而该类依赖于 AppSettings 然后您的班级仍然与 AppSettings 耦合。换句话说，他们别无他法。如果您想对课程进行单元测试，那就是一个挑战。这意味着您的单元测试项目必须具有相同的< appSettings> 部分。但是，如果要使用设置使用两个不同值的两个测试怎么办？不可能。或者，如果您有一个需要设置的类，并且几年后想在ASP.NET Core应用程序中使用它而没有web.config，该怎么办？

If your classes depend on a static class and that class depends on AppSettings then your classes are still coupled to AppSettings. In other words, there's no other way for them to get their settings. That's a challenge if you want to unit test your class. That means that your unit test project has to have the same <appSettings> section. But what if you want two tests that use two different values for a setting? It's impossible. Or what if you have a class that needs settings and in a few years you want to use it in an ASP.NET Core application and there is no web.config? Then it won't work at all.

为避免这种情况，您可以执行以下操作：

To avoid that you can do this:

public interface IMySettings
{
    string Setting1 {get;}
    string Setting2 {get;}
}

public class MyConfigurationSettings : IMySettings
{
    public string Setting1
    {
        get { return ConfigurationManager.AppSettings["SomeKey"].ToString(); }
    }
    public string Setting2
    {
        get { return ConfigurationManager.AppSettings["SomeOtherKey"].ToString(); }
    }
}

然后，在需要设置的类中：

Then, in the class that needs the setting:

public class ClassThatNeedsSettings
{
    private readonly IMySettings _settings;

    public ClassThatNeedsSettings(IMySettings settings)
    {
        _settings = settings;
    }
}

然后，当您创建<$的实例时c $ c> ClassThatNeedsSettings ，您传递实现 IMySettings 的类的实例，该类将使用该实例来检索设置。当您的应用程序运行时，您传入 MyConfigurationSettings ，以便您的值来自 AppSettings 。但是 ClassThatNeedsSettings 从来都不知道。它仅知道它正在使用 IMySettings 的实例。

Then, when ever you create an instance of ClassThatNeedsSettings you pass an instance of a class that implements IMySettings, and the class will use that to retrieve settings. When your application is running you pass in MyConfigurationSettings so that your values come from AppSettings. But ClassThatNeedsSettings never knows that. It only knows that it's using an instance of IMySettings.

这称为依赖注入。 ClassThatNeedsSettings 取决于 IMySettings ，因此您可以将其注入到构造函数中。这样， ClassThatNeedsSettings 会收到所需的内容。它不负责创建它。

This is called "dependency injection." ClassThatNeedsSettings depends on IMySettings so you're "injecting" it into the constructor. That way ClassThatNeedsSettings receives what it needs. It's not responsible for creating it.

如果要进行单元测试，可以模拟 IMySettings 。也就是说，您可以创建实现该接口的其他类，并使用它们传递要测试的任何值。甚至还有Moq之类的工具可以帮助您创建这些类。

If you want to unit test, you can "mock" IMySettings. That is, you can create other classes that implement the interface and use them to pass in whatever values you want to test with. There are even tools like Moq that help you create those classes.

通常，如果您使用依赖注入，那么您还将使用Windsor，Unity，Autofac，或其他人来为您管理创建对象。感觉有点像诱饵和切换在最后引入了它，因为它需要更多的学习，并且可能会更改应用程序的配置方式。但这就是为什么我们使用它，以防止一个类对另一个类具有绝对的依赖关系，这使得它的灵活性和测试难度降低。

Typically if you use dependency injection you're also going to use a framework like Windsor, Unity, Autofac, or others to manage creating objects for you. It feels a little bit like bait-and-switch introducing that at the very end because it requires more learning and perhaps changing the way an application is configured. But this is why we use it, to prevent one class from having an absolute dependency on another which makes it less flexible and harder to test.

这篇关于使用静态类来促进对设置的访问是否可以接受？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！