Как бы вы централизовали конфигурацию для нескольких проектов?
У меня есть решение с примерно 10 проектами с конфигурацией только для чтения. Это веб-приложения, службы Windows, консольные приложения и т. Д. Все проекты, кроме одного, находятся на одном сервере. Каждый проект имеет 3 среды - dev, test и production. Таким образом, существует 30 различных наборов конфигурации, каждый с приличным количеством настроек. Поддерживать согласованность конфигурации для каждого приложения и среды неудобно.
Я заметил, что большая часть конфигурации одинакова для каждого проекта, поэтому я подумал, что было бы хорошо каким-то образом централизовать конфигурацию. Я где-то читал, что сервис WCF может быть хорошим подходом. Я подумал, что, возможно, библиотека, содержащая жестко закодированный статический класс, может работать нормально - несмотря на необходимость компиляции для изменения конфигурации. В идеале конфиг должен исходить из реального файла .config.
Как бы вы пошли о централизации конфигурации для нескольких проектов?
3 ответа
Если вы хотите сохранить стандартный интерфейс конфигурации, взгляните на ProtectedConfigurationProvider. Этот провайдер позволяет хранить данные конфигурации вне стандартного файла конфигурации, шифровать их любым удобным для вас способом или перенаправлять запросы на настройку любым удобным для вас способом:
- Перенаправление конфигурации с помощью пользовательского провайдера — Wrox
- Реализация защищенного Поставщик конфигурации — MSDN
- Защищенная конфигурация — Blayd Software
Прелесть этого подхода в том, что в ваших существующих приложениях ничего не меняется. Им не нужно знать, где хранится их конфигурация. Извлечение данных конфигурации изолировано в провайдере. Вы можете сохранить его в центральном файле, в базе данных или получить к нему доступ через веб-службу. Если вы передумаете, вам нужно будет только обновить своего провайдера. Все остальное остается прежним.
Поскольку они (почти) все находятся на одном сервере, вы можете указать значения по умолчанию в файлах machine.config и/или в центральных файлах web.config. Обычно я не сторонник использования/изменения этих файлов, но они есть... в \Windows\Micsrosoft.NET\Framework<версия>\Config\
Вы, безусловно, можете настроить службу WCF, которая имеет простую операцию для получения параметров конфигурации, используя приложение и среду в качестве параметра; затем вы можете заставить службу загрузить правильную конфигурацию из файла и вернуть ее вызывающей стороне. Может быть хорошей идеей сделать вложенные файлы конфигурации, чтобы общие настройки определялись только один раз на их самом общем уровне.
Потенциальная проблема может возникнуть, если служба WCF не работает при запуске одного из ваших приложений — вам нужно будет решить, существует ли конфигурация/кэширование предыдущей копии по умолчанию для этой ситуации, или вы просто не разрешить запуск приложений, если они не могут подключиться.
Еще одна вещь, которую следует учитывать, — это преимущество файлов .config в .NET, заключающееся в том, что когда они изменяются, приложение может реагировать; вам может понадобиться служба обратного вызова WCF, которая уведомляет клиентов об обновлении их конфигурации на центральном сервере, чтобы они могли запросить новую копию и при необходимости обновить себя.