Должны ли «службы» моей программы отвечать за получение собственной конфигурации?

Question

Моя программа состоит из нескольких «сервисов» (я не говорю о SOA , так что не запутайтесь), и каждый из этих «сервисов» использует некоторую конфигурацию (например, путь к каталогу). Эта конфигурация должна быть прочитана из файла конфигурации, поскольку они имеют тенденцию изменяться (без изменения логики программы, то есть).

Итак, мой вопрос заключается в следующем: должна ли каждая «служба» получать свою конфигурацию при вызове или она должна отвечать за получение своей собственной конфигурации?

Этот вопрос на самом деле очень похож на этот вопрос, только мой конкретнее о них:

• «Услуги» моей программы не являются общими и не должны использоваться другими. Они уже используют универсальные инструменты, и их функциональность заключается в простом соединении между этими инструментами. Это означает, что им не сразу очевидно, что они получили свою конфигурацию, поскольку их цель очень ясна и прямолинейна.
• Цель этих «услуг», будучи ясной и прямой, иногда требует более одного действия. Это означает, что мои «службы» не обязаны отвечать только за одно действие (хотя вы можете разделить логику и подготовку, например, настройку).

Спасибо.

Answer 1

Я бы выступил за сочетание этих подходов, если вам удастся реализовать его элегантным способом (я видел, как это делается как в элегантных, так и в ужасных реализациях):

• Иметь структуру данных для конфигурации, которая может реализовывать подмножества настроек (в Perl это очень просто с наложенными хэшами, в других языках это немного более многословно, но наложение карт друг на друга также работает). Чтобы быть более точным, ваши структуры данных будут

  • Глобальная карта Singleton Configuraton

  • Карта локальных настроек "передано в качестве параметра"

• Иметь класс загрузчика конфигурации, который может:

  • Взять "передано в качестве параметра" карту локальной конфигурации

  • Возьмите набор ключей, необходимый компоненту

  • Наложение локальной карты на карту глобальной конфигурации

  • Разрешить компонентам запрашивать значения из объединенной карты.

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

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

Answer 2

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

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

Для сервисов, которым требуются динамические конфигурации, я обычно отправляю сообщение «config config» своему сервису, по сути говоря, для безопасной перезагрузки с новой конфигурацией.