До сих пор во всех моих проектах я использовал одноэлементный шаблон для доступа к конфигурации приложения во всем приложении. В последнее время я вижу много статей о том, чтобы не использовать шаблон singleton, потому что этот шаблон не способствует тестируемости, а также скрывает зависимость Component. У меня вопрос: как лучше всего хранить конфигурацию приложения, которая легко доступна во всем приложении, не передавая объект конфигурации по всему приложению?
Заранее спасибо
Мадху
Я думаю, что конфигурация приложения - отличное использование шаблона Singleton. Я стараюсь использовать его сам, чтобы не перечитывать конфигурацию каждый раз, когда я хочу получить к ней доступ, и потому, что мне нравится, чтобы конфигурация была строго типизированной (т.е. мне не приходилось каждый раз преобразовывать нестроковые значения). Я обычно встраиваю некоторые методы бэкдора в свой синглтон для поддержки тестируемости, т. Е. Возможность вводить конфигурацию XML, чтобы я мог установить ее в своем тесте, и возможность уничтожить синглтон, чтобы он был воссоздан при необходимости. Обычно это частные методы, к которым я обращаюсь через отражение, поэтому они скрыты от общедоступного интерфейса.
РЕДАКТИРОВАТЬ Мы живем и учимся. Хотя я считаю, что конфигурация приложения - одно из немногих мест, где можно использовать синглтон, я больше этим не занимаюсь. Обычно сейчас я создаю интерфейс и стандартную реализацию класса, используя статические Lazy<T> поля поддержки для свойств конфигурации. Это позволяет мне иметь поведение «инициализировать один раз» для каждого свойства с лучшей проверкой тестируемости.
Используйте внедрение зависимостей, чтобы внедрить единый объект конфигурации в любые классы, которые в нем нуждаются. Таким образом, вы можете использовать фиктивную конфигурацию для тестирования или чего угодно ... вы явно не выходите и не получаете то, что нужно инициализировать с помощью файлов конфигурации. При внедрении зависимостей вы также не передаете объект.
Для этой конкретной ситуации я бы создал один объект конфигурации и передал бы его тем, кому он нужен.
Поскольку это конфигурация, она должна использоваться только в определенных частях приложения и не обязательно должна быть вездесущей.
Однако, если у вас не было проблем с их использованием и вы не хотите так сильно тестировать, вам следует продолжать делать то же самое до сегодняшнего дня.
Прочтите обсуждение того, почему они считаются вредными. Я думаю, что большинство проблем возникает, когда синглтон удерживает много ресурсов.
Что касается конфигурации приложения, я думаю, было бы безопасно оставить все как есть.
Похоже, что одноэлементный шаблон - лучший вариант. Вот написанный мной Setting класс, который мне подходит.
Если какой-либо компонент полагается на конфигурацию, которая может быть изменена во время выполнения (например, поддержка темы для виджетов), вам необходимо предоставить некоторый механизм обратного вызова или сигнализации для уведомления об измененной конфигурации. Поэтому недостаточно передать компоненту только необходимые параметры во время создания (например, цвет). Вам также необходимо предоставить доступ к конфигурации изнутри компонента (передать полную конфигурацию компоненту) или создать фабрику компонентов, которая хранит ссылки на конфигурацию и все созданные ею компоненты, чтобы она могла в конечном итоге применить изменения.
У первого есть большой недостаток: он загромождает конструкторы или взрывает интерфейс, хотя, возможно, он самый быстрый для прототипирования. Если принять во внимание «Закон Деметры», это большой отказ, потому что он нарушает инкапсуляцию. У последнего есть то преимущество, что компоненты сохраняют свой особый интерфейс, где компоненты берут только то, что им нужно, и в качестве бонуса дает вам центральное место для рефакторинга (фабрику). В долгосрочной перспективе при обслуживании кода, вероятно, выиграет от фабричного паттерна.
Кроме того, даже если бы фабрика была одноэлементной, она, вероятно, использовалась бы в гораздо меньшем количестве мест, чем синглтон конфигурации.
Вот пример, сделанный с использованием Castale.Core >> DictionaryAdapter и StructureMap
