Блог

Я ищу наилучшую практику для управления конфигурацией в проекте с несколькими библиотеками классов. Я ищу удобство обслуживания и простоту реализации.

Давайте рассмотрим простой пример: консольный проект с 2 библиотеками классов. Каждой библиотеке классов нужны свои собственные настройки конфигурации, и есть некоторые настройки, которые являются общими для нескольких.

Библиотека классов 1

• Настройка cl1
• Глобальная настройка

Библиотека классов 2

• CL2Setting
• Глобальная настройка

Первым подходом было бы создать все необходимые настройки в основном проекте:

• Глобальная настройка
• Настройка cl1
• CL2Setting

Но это создает несколько проблем:

• При большом количестве настроек он может быстро загромождаться.
• Это непросто поддерживать: как узнать, какие настройки необходимы для каждой библиотеки?
• Это может привести к конфликтам именования. Что, если CL1Setting и CL2Setting будут иметь одно и то же имя?

Идеальным решением для меня (хотя, боюсь, это невозможно) было бы иметь пользовательские настройки библиотеки в отдельных файлах или, по крайней мере, в разных разделах. Что-то вроде этого:

 <configuration>
  <appSettings>
    <add key="globalSetting" value="cl1Global"/>
  </appSettings>
  <appSettings file="CL1.config" >
    <add key="cl1setting" value="cl1setting1"/>
  </appSettings>
  <appSettings file="CL2.config">
    <add key="cl2setting" value="cl2setting2"/>
  </appSettings>
</configuration>
  

Есть предложения?

Редактировать

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

РЕДАКТИРОВАТЬ 2

джозеф.феррис предлагает посмотреть на конструктор разделов конфигурации в CodePlex (csd.codeplex.com ) было хорошо. Я обнаружил дополнительные проблемы, о которых сообщается здесь (в случае, если кому-то интересно)http://csd.codeplex.com/discussions/278354

Я думаю, что вы ищете пользовательский раздел конфигурации вместо настроек приложений. Это обычно используется сторонними библиотеками (log4net — первое, что приходит на ум), чтобы предоставить способ настройки их параметров через ваше приложение / файл веб-конфигурации. Обратите внимание, что это также обеспечивает основу для того, как MS создает свои разделы конфигурации.

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

Вы могли бы использовать свое собственное соглашение об именовании, чтобы снизить риск конфликтов имен приложений. И / или создавать пользовательские разделы конфигурации.

 <configuration>
  <appSettings>
    <add key="Shared.Setting1" value="..."/>

    <add key="CL1.setting1" value="..."/>
    <add key="CL1.setting2" value="..."/>

    <add key="CL2.setting1" value="..."/>
    <add key="CL2.setting2" value="..."/>

  </appSettings>
</configuration>
  

Я не уверен, что администратору нужно знать, какой параметр принадлежит какой библиотеке, но соглашение об именовании помогает продвигать логическую группировку — я бы использовал значимые для администратора префиксы, а не произносил имя библиотеки классов — например, «Ведение журнала». для настроек приложений, связанных с ведением журнала.

Microsoft использует двоеточие в качестве разделителя пространства имен в некоторых своих кодах. Пример их образцов Azure. Здесь они используют ida: в качестве префикса.

 ConfigurationManager.AppSettings["ida:ClientId"];
  

В Microsoft ASP.NET в файле Web.config вы можете увидеть:

 <appSettings>
  <add key="webpages:Enabled" value="false" />
</appSettings>