Управление большим количеством файлов app.config

У нас есть много служб Windows и веб-приложений, которые полагаются на множество общих настроек. В настоящее время мы используем только appSettings по мере необходимости, и на них ссылается ключ. Некоторые из настроек являются специфичными для приложения и известны только команде приложений, в то время как другие относятся к среде и знают только команду развертывания. Также у нас есть проблемы, когда мы должны внести изменения в общие настройки, требующие изменения 100 файлов и перезапуска всех соответствующих сервисов. С большим разнообразием настроек есть дубликаты, которые больше не используются, и многие из них не означают одно и то же для разных приложений.

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

Мой вопрос заключается в том, что я изобретаю колесо, есть ли хорошие рамки /проекты /продукты, предназначенные для управления многими файлами конфигурации в распределенной среде, и если это не тот подход, который я решил принять разумным.

7 голосов | спросил rerun 23 Maypm11 2011, 18:49:04

4 ответа


0

Я предлагаю использовать на вашем рабочем месте какую-то вики или механизм документации.

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

Конечно, это только устранит проблему, которую ваши коллеги не знают, что и как вы работаете.

Для управления настройками - просто разделите их. Если некоторые настройки необходимы специально для приложения, почему приложение не имеет собственного файла конфигурации? По моему мнению, общие настройки должны реагировать только на окружающую среду, в то время как пользовательские настройки приложения должны иметь настройки для собственных целей [приложений], не пугайтесь для умножения настроек, потому что вы сможете управлять этими настройками, не опасаясь, что вы потерпите крах некоторые другие приложения. Если вы считаете, что управление таким количеством настроек сложнее, помните, что обычной практикой является использование одного файла для каждой модели. Почему бы не сделать то же самое с настройками? Также есть опция Name_spacing, но в этом случае ваш файл конфигурации будет ОГРОМНЫМ, поэтому я предлагаю вам использовать специальные настройки, как это предлагал @Travis.

ответил JackLeo 31 Mayam11 2011, 10:17:31
4

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

ответил Erin 31 Mayam11 2011, 07:56:38
2

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

ответил Ennad 31 Mayam11 2011, 11:06:25
1

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

\Software\Services
    shared.config
    \Service1
        service1.exe
        service1.exe.config
    \Service2
        service2.exe
        service2.exe.config

В этом случае у вас есть только service1 и service2 ссылается на shared.config.

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

Изменить, я должен был включить ссылку на пример http :. //weblogs.asp.net/pwilson/archive/2003/04/09/5261.aspx

ответил Travis 31 Mayam11 2011, 06:36:18

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132