Отражение и атрибуты в архитектуре плагина

Question

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

Поскольку Reflection включает в себя снижение производительности, и я ожидаю, что через некоторое время появятся несколько плагинов, я подумал, было бы полезно определить пользовательский атрибут, применяемый на уровне сборки, который можно было бы проверить перед итерацией по типам. (возможно, около десятка типов в сборке, в том числе 1 разработчик IPluginModule).

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

Повысит ли это производительность или это просто не имеет значения по сравнению со временем, которое фактически требуется для загрузки сборки из хранилища? Кроме того, будет ли это использование уместным для атрибута вообще?

Answer 1

Я отвечу на ваш вопрос вопросом: почему вы беспокоитесь об этом?

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

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

Answer 2

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

Answer 3

Я полагаю, что обе платформы Microsoft .net для плагинов .net, Managed AddIn Framework (MAF) и Managed Extensibility Framework (MEF) могут использовать атрибуты или рефлексию для обнаружения плагинов. Поэтому Microsoft, похоже, считает, что атрибуты уместны.

Хотя я не уверен, в чем разница в производительности.

Answer 4

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

Это в основном подход, которому следует Mono.Addins framework .

Answer 5

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