是否有充分的理由更喜欢反思而不是参考

本文关键字：参考 更喜欢 理由 是否 | 更新日期: 2023-09-27 18:31:37

浏览了一些遗留代码，我遇到了一段使用反射来加载其源代码可用的 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）您可以添加新DLL的reference，更改条件检查并使其工作。

2）您可以使用 reflection ，在运行时传递条件和程序集名称，这允许您在运行时添加任意数量的功能，而无需在主应用程序中更改任何代码。

相关文章：