Методы классификации библиотек DLL плагинов - PullRequest
Новая
       6

Методы классификации библиотек DLL плагинов

1 голос
/ 26 сентября 2011

В моей команде мы создаем приложение .NET (WinForms), которое загружает дополнительные сборки (DLL) в качестве подключаемых компонентов.

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

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

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

Нам нужен какой-то метод для сопоставления различных библиотек DLL сейчас (и в будущем)и держите все это в синхронизации.

Некоторые предложения, которые у нас были:

  1. Атрибуты - пометьте каждую сборку некоторым атрибутом и запустите какой-нибудь пользовательский инструмент во время сборкидля создания какого-либо файла сопоставления, в соответствии с этими атрибутами.

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

  2. Файл конфигурации - добавление файла конфигурации для сборки (на практике это редко используется.поверьте) и содержат там необходимую информацию в некоторой форме.

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

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

Есть ли другие хорошие варианты для встречитакое требование?Кроме того, есть ли другие плюсы / минусы, которые я не рассмотрел с представленными решениями?

1 Ответ

2 голосов
/ 26 сентября 2011

Первый вопрос, который вы должны задать здесь:

  • кто должен иметь возможность изменять отображение сборки <-> категории?
  • может каждый ваш плагинсборки связаны с произвольной категорией, или это не имеет смысла / может быть причиной ошибок?
  • Достаточно ли, когда изменение категории происходит во время установки обновления?

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

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

...