Лучший способ для DLL получить информацию о конфигурации?

Question

Мы разработали несколько пользовательских библиотек DLL, которые вызываются сторонними приложениями Windows. Эти библиотеки загружаются / выгружаются по мере необходимости.

Большинство библиотек DLL вызывают веб-службы, и им необходимо настроить URL, тайм-ауты и т. Д.

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

Есть ли лучший способ справиться с этим?

Примечание. Настраиваемая информация содержится в файле xml, поэтому ИТ-отдел может вносить необходимые изменения. Они не будут принимать изменения реестра.

Примечание. Эти dll обслуживают ряд сторонних приложений. По сути, они реализуют внешний интерфейс EDMS. Поставщики не принимают передачу обязательных параметров.

Примечание. Это приложение .NET, а dll написано на C #. По сути, есть как толстые (приложение Windows), так и тонкие клиенты, которые обращаются к этой dll, когда им нужно выполнить какую-то операцию EDMS. Интерфейс EDMS определяется как набор вызовов, которые должны быть реализованы в dll, и dll решает, как реализовать функции EDMS, например, для некоторых клиентов «Зарегистрировать документ» обновит БД, а для других тот же вызов будет использовать стороннюю систему EDMS. Клиентов ASP нет.

Насколько я понимаю, DLL загружается, когда клиент хочет получить доступ к операции EDMS, а затем выгружается, когда вызов завершен. Клиенту может не потребоваться какое-то время выполнять другую операцию EDMS (в некоторых случаях более часа).

Answer 1

Я думаю, вам нужно предоставить больше информации. Существует много подходов к сохранению информации о конфигурации. Мы даже не знаем платформу разработки. .Net?

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

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

3. Если это ASP, Ваш Уровень доверия будет очень важен при выборе метода сохранения конфигурации.

4. Возможно, вы сможете использовать «Область приложения» вашего сервера приложений. Который загружается один раз за всю жизнь приложения. Ваша DLL может сделать эти данные недействительными, если обнаружит, что они тоже нужны.

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

Хотите уточнить дальше?

EDIT. Учитывая ваши разъяснения, я бы пошел с файлом XML. Этот пользовательский файл XML будет загружен с использованием предварительно заданного и задокументированного пути поиска. Если это ASP.Net, вы можете использовать Server.MapPath (), например, для проверки различных папок, таких как App_Data. DLL сначала проверит текущий каталог на наличие файла конфигурации. Затем вы можете использовать «менеджерский» поток, который хранит данные конфигурации и передает их любым дочерним потокам, которые в них нуждаются. Общий доступ может использовать IPC как сегмент общей памяти.

Это кажется хлопотным, но вы должны хранить информацию в некоторой области ... Либо с диска, памяти (область приложения, область сеанса, глобальная область DLL, другой процесс / IPC и т.д.)

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

Почему вы считаете, что ваша DLL удалена из памяти?

Answer 2

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

Answer 3

Один из способов сделать это состоит в том, чтобы в DLL был интерфейс, в котором указывались бы необходимые настройки.

Тогда дело за «проектом приложения» - иметь класс, который реализует этот интерфейс и передает его в DLL при инициализации, это позволяет вам свободно менять реализацию в зависимости от проекта. Один может читать из web.config, а другой - из БД.

Answer 4

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

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

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

Я мог бы рассказать вам, как это сделать в C ++. Не уверен, как бы вы сделали это в C #. GetModuleHandle + выполнение дополнительного вызова LoadLibrary для этого дескриптора - вот как я мог бы сделать это в C ++.

Answer 5

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

DLL обычно не должны «настраивать себя», так как они никогда не могут быть уверены, в каком контексте они используются. Разные пользователи (как в приложениях) могут иметь разные настройки конфигурации.

Поскольку вы сказали, что приложение написано на .NET, вам, вероятно, следует просто потребовать, чтобы они поместили необходимую конфигурацию для функций вашей DLL в их файл конфигурации ("what.exe.config") и доступ к нему из вашей DLL через AppSettings или, что еще лучше, через пользовательский раздел конфигурации.

Кроме того, вы можете указать разумные значения по умолчанию для настроек, где это возможно (хотя, возможно, не для сетевых адресов).

Answer 6

Как часто выгружается dll? COM-библиотеки могут контролировать, когда они выгружаются с помощью метода DllCanUnload. Если это COM-компоненты, вы можете посмотреть здесь реализацию некоторого времени ожидания, чтобы предотвратить частые загрузки и выгрузки. Если dll не перезагружает конфигурацию на значительной частоте, вряд ли это будет узким местом для реальной производительности.

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

Answer 7

Почему бы вам не позволить вызывающему приложению заполнить структуру данных всем необходимым? Может быть сделано как часть вызова инициализации или около того.