это хороший дизайн, чтобы иметь отдельный файл конфигурации для DLL?

Question

Это хороший дизайн, чтобы иметь отдельный файл конфигурации для вас DLL?

Я заметил, когда DLL вызывается из приложения, он не читает его.

что такое DLLможет прочитать файл machine.config.

Answer 1

Зависимость dll от файла конфигурации не идеальна и может стать настоящей болью, когда вы начинаете модульное тестирование или перемещаете его.

Лучшее решение - передать любые значения из настроек конфигурации из вызывающегоприложение, например, WebApp или Windows App и т. д., и сохраните все параметры, необходимые в приложении или веб-конфигурации.

Answer 2

Похоже, у вас есть два отдельных вопроса.

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

2. DLL, безусловно, могут читать файлы.Убедитесь, что DLL читает файл из правильного местоположения (например, проверьте текущий рабочий каталог).

Answer 3

Это действительно зависит от использования. Для DLL, которая является просто частью основного приложения, нет. Однако для некоторых сценариев плагинов может быть удобнее включить специфичную для библиотеки конфигурацию, загрузку которой вы должны будете обеспечить в самой сборке. Вы также можете сделать это, изменив собственный конфигурационный файл приложения, если он есть.

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

<IPluginConfiguration>
      <PluginSpecificSetting name="PluginName">Value</PluginSpecificSetting>
</IPluginConfiguration

или вы можете использовать подраздел в app.config, что-то вроде

<configuration>
     <PluginSettings>
         <Plugin1>
             <PluginSpecificSetting name="PluginName">Value</PluginSpecificSetting>
         </Plugin1>
     </PluginSettings>
</configuration>

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

Answer 4

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

В этом сценарии DLL не нужно будет читать файл конфигурации.

Мои соображения сводятся к разделению проблем.Если цель библиотеки DLL - не читать файлы на жестком диске, она не должна читать файлы на жестком диске.

Answer 5

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