寻找动态加载 DLL 的优势,而不是让您的应用程序默认加载 DLL。
6 回答
一个优点是支持插件架构。
例如,假设您要编写一个按计划执行不同类型任务的服务。这些任务正在做什么,实际上与您的核心服务无关,核心服务只是在正确的时间启动它们。而且,您很有可能希望添加支持以在将来执行其他类型的任务(或者其他开发人员可能想要)。在这种情况下,通过实现插件方法,它允许您插入更多(通过接口兼容)可以独立于核心服务进行编码的 dll。因此,添加对新任务的支持不需要重新构建/部署整个服务。如果需要更改特定任务,只需重新部署该 dll,然后自动拾取即可。
它还要求其他开发人员自己不关心服务,他们只需要知道要实现什么接口就可以获取它。
我们将这种架构用于我们的处理应用程序,以处理我们不同客户所需的差异。每个 DLL 具有相似的结构并实现相同的接口和入口方法“Process()”。我们有一个 XML 文件,它根据客户定义要加载的类以及除了需要调用的过程之外是否还有更多方法。在您的事务计数变得非常高之前,性能应该不是问题。
动态加载共享对象是允许插件临时运行应用程序的机制。如果没有插件,则必须在链接时或编译时将模块化应用程序放在一起(查看 nginx 的代码)。
您的问题是关于 C#/.NET,因此在这个世界上,动态 DLL 加载需要高级编程技能。这可以补偿动态 DLL 加载的所有潜在好处。您只需要编写很多“低级”代码。
在 C++/Win32 中,当 DLL 具有一些在旧操作系统上不可用的新 API 函数时,我经常必须动态加载 DLL。在这种情况下,我需要确保此 API 在运行时的可用性。我不能只链接这个 DLL,因为它会导致旧操作系统上的应用程序加载错误。
如前所述,您还可以在基于插件的环境中获得一些好处。在这种情况下,如果动态加载 DLL,您将对资源有更多的控制。本质上,COM 是动态 DLL 处理的一个很好的例子。
如果您只加载您需要的 DLL,那么应用程序的启动时间应该会更快。
动态加载 DLL 的另一个原因是为了健壮性。
可以将 DLL 加载到所谓的 AppDomain 中。Appdomain 基本上是一个沙盒容器,您可以将内容放入(DLL 的部分或整个 EXE)中,以便在您的应用程序中单独运行。
除非您调用包含在 AppDomain 中的类型,否则它无法与您的应用程序交互。
因此,如果您有一个狡猾的第三方 DLL,或者您没有源代码的 DLL,您可以将其加载到 AppDomain 中以使其与您的主应用程序流隔离。
最终结果是,如果第三方 DLL 抛出一个 wobbly,只有 appdomain 而不是您的整个应用程序会受到影响。