插件架构中的反射与属性 [英] Reflection vs. Attributes in plugin architecture

问题描述

我正在开发一个在启动时从子目录加载插件的应用程序，目前我正在通过使用反射来迭代每个程序集的类型并查找实现 IPluginModule 接口的公共类来实现这一点.

I am working on an application that loads plugins at startup from a subdirectory, and currently i am doing this by using reflection to iterate over the types of each assembly and to find public classes implementing the IPluginModule interface.

由于反射会影响性能，并且我预计一段时间后会有几个插件，我想知道定义在程序集级别应用的自定义属性是否有用，可以在迭代类型之前进行检查(可能在一个程序集中有十几种类型，包括 IPluginModule 的 1 个实现者).

Since Reflection involves a performance hit, and i expect that there will be several plugins after a while, i wondered if it would be useful to define a custom attribute applied at the assembly level, that could be checked before iterating over the types (possibly about a dozen types in an assembly, including 1 implementor of IPluginModule).

该属性(如果存在)可以提供返回所需类型或实例的方法，然后对类型进行迭代将只是一种回退机制.不能将类型信息存储在配置文件中.

The attribute, if present, could then provide a method to return the needed types or instances, and iterating over the types would then only be a fallback mechanism. Storing the type info in a configuration file is not an option.

这会提高性能，还是与从存储加载程序集的实际时间相比无关紧要?另外，这种用法是否适合某个属性?

Would this improve performance, or does it just not matter compared to the time to actually takes to load the assembly from storage? Also, would this usage be appropriate for an attribute at all?

推荐答案

我会用一个问题来回答你的问题:你为什么担心这个?

I will answer your question with a question: Why are you worried about this?

您担心在一次性操作中潜在性能受到影响，因为以后可能有多个插件.

You're worrying about a potential performance hit in a one time operation because there might be several plugins at a later date.

除非您的应用程序启动时间对用户来说过长，否则我不会浪费时间去考虑它 - 您可能有很多更好的方法可以改进您的应用程序.

Unless your application startup time is excessively long to a user, I wouldn't waste time thinking about it - there are probably much better things that you can work on to improve your application.

这篇关于插件架构中的反射与属性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！