回顾一些遗留代码,我遇到了一段代码,它使用反射来加载一些它们的源代码可用的 dll(它们是解决方案中的另一个项目)。
我绞尽脑汁想弄清楚为什么会这样(当然,代码没有记录在案……)。
我的问题是,你能想出什么好的理由更喜欢通过反射而不是引用它来加载程序集吗?
回顾一些遗留代码,我遇到了一段代码,它使用反射来加载一些它们的源代码可用的 dll(它们是解决方案中的另一个项目)。
我绞尽脑汁想弄清楚为什么会这样(当然,代码没有记录在案……)。
我的问题是,你能想出什么好的理由更喜欢通过反射而不是引用它来加载程序集吗?
是的,如果您有一个动态模块系统,则应根据运行时的条件加载不同的 DLL。我们在我工作的地方这样做;我们对可能加载到我们系统中的不同可选模块进行许可检查,然后仅在许可签出时加载与每个模块关联的 DLL。这可以防止加载永远不应该执行的代码,这既可以稍微提高性能,又可以防止错误。
动态加载 DLL 还可以让您在不更改任何源代码的情况下彻底更改功能。例如,主程序集可以启动一个发现过程,在该过程中它找到实现某个接口的所有类,并根据某些运行时标准选择要使用的类。
如今,您通常希望将MEF用于此类任务,但这仅在 .NET 4.0 之后才出现,因此可能有许多代码库可以手动完成。(我对 MEF 了解不多。也许你也必须在那里手动完成这部分。)
但无论如何,您的问题的答案是肯定有充分的理由使用反射动态加载 DLL。如果没有更多细节,就不可能说它是否适用于您的情况。
在不了解您的具体项目的情况下,这里没有人可以告诉您为什么在您的情况下这样做。
但一般的原因是:
可更新性:您可以简单地重新编译和替换更新的库,而不必重新编译和替换整个应用程序。
合作:如果界面清晰,那么多个团队可以一起工作。一个用于主应用程序,另一个用于 dll
可重用性:有时您需要在多个项目中使用相同的功能,因此可以反复使用相同的 dll
可扩展性:在某些情况下,您希望以后能够使用在发货时不存在的插件来扩展您的程序。这可以使用 dll 来实现。
我希望这可以帮助您了解一些设置..
Reason for loading an assembly via reflection rather than referencing it?
让我们考虑一个场景,其中有三个类具有DoWork()
该方法返回的方法string
,您通过检查条件(强类型)来访问它。
现在您在两个不同的 DLL 中多了两个类,您将如何应对这种变化?
1)您可以添加reference
新的DLL,更改条件检查并使其工作。
2)您可以在运行时使用reflection
、传递条件和程序集名称,这允许您在运行时添加任意数量的功能,而无需在主应用程序中更改任何代码。