Плохо ли иметь глобальный класс Config?

Question

В настоящее время на своем личном веб-сайте, который я создаю, я использую глобальный статический класс Config для хранения всего настраиваемого, что мне может потребоваться изменить, что является полуглобальным. Так что сейчас это выглядит примерно так:

public static class Config
{
    public static string ConnectionString = "mongodb://localhost";
    //more configuration options..
    public static MongoDB.Driver.MongoDatabase GetDB(){
        MongoServer server = MongoServer.Create(Config.ConnectionString);
        MongoDatabase db = server.GetDatabase(Config.Database);
        return db;
    }
    public static Markdown GetMarkdown(){
        var options=new MarkdownOptions(){
            AutoHyperlink=true,
            AutoNewlines=false,
            EmptyElementSuffix=" />",
            LinkEmails=false,
            StrictBoldItalic=true
        };
        var m=new Markdown(options);
        return m;

    }
}

Является ли использование глобального класса конфигурации, подобного этому, своего рода анти-паттерном? Кроме того, я предпочитаю, чтобы мои строки подключения находились вне web.config. Мне нравится, что мой web.config должен быть минимально возможным.

Answer 1

Я делаю что-то похожее на это, но не для настроек, таких как строки подключения. Если необходимо изменить строку подключения, необходимо обновить и перестроить проект. Если вы сохранили строку подключения в своем файле web.config, простое обновление позволит вашему приложению немедленно использовать новый параметр (без перекомпиляции).

Answer 2

Ну, из 3-х членов только 1 действительно сконфигурирован, два других действительно полезны.

Наличие конфигурации в скомпилированном коде действительно сложно поддерживать, если эти конфиги необходимо изменить, так как это требует перестройки, что действительно является причиной для файлов конфигурации.

Answer 3

Анти-паттерн состоит в том, что у вас есть GetMarkdown и ConnectionString в одном классе , потому что они оба статичны, но в действительности у них нет функциональных отношений . GetMarkdown и GetDB оба выглядят как фабричные методы и, вероятно, они должны быть в своих собственных классах.

Принцип единой ответственности гласит, что вы должны группировать вещи, которые могут измениться по той же причине. Маловероятно, что ваше подключение к базе данных и конфигурация уценки изменятся одновременно или по той же причине.

Answer 4

Эрлз,

Что касается вашего второго вопроса, вы можете сделать что-то вроде этого, нет необходимости иметь все соединения или конфигурации в web.config. Вы можете иметь отдельный файл конфигурации и указать его в файле web.config, как показано ниже

<connectionStrings configSource="config\yourpath\connectionStrings.config"/>

По первому вопросу напишите общий метод получения значений. Загрузите все значения в файл констант и напишите вспомогательный класс, чтобы получить эти значения

Answer 5

Мы перенесли наши настройки в базу данных.Облегчает это при переходе с Dev на QA на Prod. Запись в блоге находится здесь.

В связи с этим мы откладываем строку подключения в сторону в WebEnvironment.config.Так что теперь мы можем продвигать наш код с изменениями web.config и не беспокоиться о строке подключения. Это сообщение в блоге здесь.