.NET: централизация сплит-конфигурации - PullRequest
0 голосов
/ 12 июня 2009

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

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

Ответы [ 3 ]

2 голосов
/ 12 июня 2009

Пара возможных решений:

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

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

1 голос
/ 12 июня 2009

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

0 голосов
/ 13 июня 2009

Как насчет этого:

  • Определите ваши настройки "dev / staging / production" в файле конфигурации проекта доступа к данным

  • Пусть клиенты (приложения) определяют, какие настройки они хотят использовать, например,

... = DataAccess.UserGateway.Create(DataAccess.Config.Dev);

и строковые константы для имен различных конфигов определены только в одном месте - в модуле DataAccess.

С другой стороны, мне очень нравится копировать конфиги во время сборки / развертывания - это так чисто.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...