Должны ли DLL иметь свои собственные файлы конфигурации?

Question

Извините, если это дубликат, но мне не удалось найти этот вопрос напрямую.

Общее мнение здесь (это я и он напротив меня) таково, что они не должны этого делать, причина в том, что библиотеки DLL могут быть общими; поэтому идея иметь специфичную для приложения информацию в DLL бессмысленна. Если информация не зависит от приложения, можно использовать константы.

Еще один вопрос, если предположить, что библиотеки DLL не имеют своего собственного файла конфигурации, должны ли библиотеки DLL использовать файлы конфигурации исполняемого файла, который загрузил библиотеку DLL, или вместо этого передавать соответствующие данные как часть какого-либо конструктора. Наше мнение здесь является последним, поскольку оно делает его более тестируемым, недостатком является то, что иногда бывает необходимо передать значительный объем данных в dll.

Мнения

Answer 1

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

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

В качестве альтернативы, используйте что-то вроде Spring.NET для управления такого рода вещами:)

Answer 2

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

У меня есть один сценарий, в котором библиотеки DLL читают файл конфигурации, но он очень особенный: .NET DLL экспортирует объекты в виде объектов COM для использования Microsoft Navision. Он связывается с банком факторинга, используя интерфейс XML-RPC.

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

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