Альтернативы для шаблона "одиночка"?

Я был веб-разработчиком в течение некоторого времени теперь использование ASP.NET и C#, я хочу попытаться увеличить свои навыки при помощи лучших практик.

У меня есть веб-сайт. Я хочу загрузить настройки однажды прочь и просто сослаться на него, где когда-либо мне нужен он. Таким образом, я провел некоторое исследование, и 50% разработчиков, кажется, используют шаблон "одиночка", чтобы сделать это. И другие 50% разработчиков являются одиночным элементом муравья. Они все ненавидят одиночные элементы. Они рекомендуют внедрение зависимости.

Почему одиночные элементы плохо? Что лучшая практика должна загрузить настройки веб-сайтов? Они должны быть загружены только однажды и сосланы при необходимости? Как я пошел бы о выполнении этого с внедрением зависимости (я являюсь новым в этом)? Есть ли какие-либо образцы, которые кто-то мог рекомендовать для моего сценария? И я также хотел бы видеть некоторый код модульного теста для этого (для моего сценария).

Спасибо Brendan

7
задан Brendan Vogt 3 July 2010 в 11:07
поделиться

3 ответа

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

Есть несколько различных способов его использования, которые по-прежнему позволят вам провести модульное тестирование вашего приложения. Один из способов (возможно, в обоих направлениях, если ваш синглтон не лениво читает app.cofnig) - это иметь файл app.config по умолчанию в вашем проекте модульного тестирования, обеспечивающий значения по умолчанию, необходимые для ваших тестов. Вы можете использовать отражение для замены любых конкретных значений, если это необходимо в ваших модульных тестах.Обычно я настраиваю частный метод, который позволяет удалить частный экземпляр синглтона в тестовой настройке, если я все же внесу изменения для определенных тестов.

Другой способ - не использовать синглтон напрямую, а создать для него интерфейс, который реализует синглтон-класс. Вы можете использовать ручную инъекцию интерфейса, по умолчанию для экземпляра синглтона, если предоставленное значение равно нулю. Это позволяет вам создать фиктивный экземпляр, который вы можете передать тестируемому классу для ваших тестов, но в вашем реальном коде используйте экземпляр singleton. По сути, каждый класс, которому он нужен, поддерживает частную ссылку на экземпляр синглтона и использует его. Мне этот способ нравится немного больше, но поскольку синглтон будет создан, вам все равно может понадобиться файл app.config по умолчанию, если только все значения не загружаются лениво.

public class Foo
{
    private IAppConfiguration Configuration { get; set; }

    public Foo() : this(null) { }

    public Foo( IAppConfiguration config )
    {
        this.Configuration = config ?? AppConfiguration.Instance;
    }

    public void Bar()
    {
         var value = this.Config.SomeMaximum;
         ...
    }
}    
6
ответ дан 7 December 2019 в 05:17
поделиться

Здесь есть хорошее обсуждение одноэлементных шаблонов и примеры кодирования ... http://en.wikipedia.org/wiki/Singleton_pattern См. Также здесь ... http://en.wikipedia.org/wiki/Dependency_injection

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

1
ответ дан 7 December 2019 в 05:17
поделиться

Шаблоны дизайна могут быть удивительными. К сожалению, синглтон, кажется, выделяется как больной палец, и во многих случаях его можно рассматривать как антипаттерн (он способствует плохой практике). Как ни странно, большинство разработчиков знают только один шаблон проектирования, и это синглтон.

В идеале ваши настройки должны быть переменной-членом в расположении высокого уровня, например, объектом приложения, которому принадлежат создаваемые вами веб-страницы. Затем страницы могут запрашивать настройки у приложения или приложение может передавать настройки по мере создания страниц.

1
ответ дан 7 December 2019 в 05:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: