动态加载DLL有什么优点？
了解动态加载 DLL 相对于让应用程序默认加载 DLL 的优势。
Looking for the advantages of loading DLLs dynamically as opposed to letting your application load the DLLs by default.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
一个优点是支持插件架构。
例如，假设您要编写一个按计划执行不同类型任务的服务。这些任务正在执行的操作实际上与您的核心服务无关，核心服务只是在正确的时间启动它们。而且，您很可能希望添加支持以在将来执行其他类型的任务（或者其他开发人员可能想要）。在这种情况下，通过实现插件方法，它允许您放入更多（通过接口兼容）的 dll，这些 dll 可以独立于核心服务进行编码。因此，添加对新任务的支持不需要重新构建/部署整个服务。如果某个特定任务需要更改，只需重新部署该 dll，然后自动拾取即可。
它还要求其他开发人员不必关心服务本身，他们只需要知道要实现什么接口，以便可以选择它。
One advantage is for supporting a plugin architecture.
Suppose for example you want to write a service that performs different types of tasks on a scheduled basis. What those tasks are doing, isn't actually relevant to your core service which is just there to kick them off at the right time. And, it's more than likely you want to add support to do other types of tasks in the future (or another developer might want to). In that scenario, by implementing a plugin approach, it allows you to drop in more (compatible by interface) dlls which can be coded independently of the core service. So, adding in support for a new task does not require a new build/deployment of the whole service. If a particular task needs to change, just that dll needs to be redeployed and then automatically picked up.
It also requires other developers to not be concerned with the service themselves, they just need to know what interface to implement so it can be picked up.
我们将这种架构用于我们的处理应用程序，以处理不同客户所需的差异。每个DLL都有相似的结构并实现相同的接口和入口方法“Process()”。我们有一个XML文件，它根据客户定义要加载哪个类以及除了进程之外是否还有更多方法需要调用。在您的交易数量变得非常高之前，性能不应该成为问题。
We use this architecture for our processing applications to handle differences that our different customers require. Each DLL has a similar structure and implements the same interface and entry method "Process()". We have an XML file that defines which class to load based on the customer and whether there are more methods besides process that needs to be called. Performance should not be an issue until your transaction count gets very high.
动态加载共享对象是允许插件临时运行应用程序的机制。如果没有插件，模块化应用程序就必须在链接时或编译时组合在一起（查看 nginx 的代码）。
Loading Shared Objects dynamically is the mechanism for allowing plugins ad hoc to running applications. Without plugins a modular application would have to be put together at link-time or compile-time (look at the code of nginx).
您的问题是关于 C#/.NET 的，因此在这个世界上动态 DLL 加载需要高级编程技能。这可以补偿动态 DLL 加载的所有潜在好处。您只需要编写大量“低级”代码即可。
在 C++/Win32 中，当 DLL 具有一些在旧操作系统上不可用的新 API 函数时，我经常必须动态加载 DLL。在这种情况下，我需要确保该 API 在运行时的可用性。我不能仅仅链接到这个 DLL，因为它会导致旧操作系统上的应用程序加载错误。
如前所述，您还可以在基于插件的环境中获得一些好处。在这种情况下，如果动态加载 DLL，您将可以更好地控制资源。本质上，COM 是动态 DLL 处理的一个很好的例子。
Your question is about C#/.NET so in this world dynamic DLL loading requires advanced programming skills. This could compensate all the potential benefits of dynamic DLL loading. You would simply have to write a lot 'low level' code.
In C++/Win32 I often have to load a DLL dynamically when this DLL has some new API function which is not available on older operating systems. In this case I need to ensure the availability of this API at runtime. I cannot just link against this DLL because it will cause application loading errors on legacy operating systems.
As mentioned, you could also have some benefits in a plugin-based environment. In this case you would have more control on your resources if loading DLLs dynamically. Essentially COM is a good example of dynamic DLL handing.
如果您只加载所需的 DLL，那么应用程序的启动时间应该会更快。
If you only load the DLLs you need then the startuptime of the application should be faster.
动态加载 DLL 的另一个原因是为了鲁棒性。
可以将 DLL 加载到所谓的 AppDomain 中。 Appdomain 基本上是一个沙箱容器，您可以将内容放入其中（DLL 的部分或整个 EXE）以隔离运行，但在您的应用程序内。
除非您调用 AppDomain 中包含的类型，否则它无法与您的应用程序交互。
因此，如果您有一个狡猾的第三方 DLL，或者您没有源代码的 DLL，您可以将其加载到 AppDomain 中，以使其与主应用程序流隔离。
最终结果是，如果第三方 DLL 引发不稳定，则只有应用程序域而不是整个应用程序受到影响。
Another reason to load DLL's dynamically is for robustness.
It is possible to load a DLL into what is known as an AppDomain. An Appdomain is basically a sand box container that you can put things into (Either portions of DLL's or whole EXEs) to run in isolation, but within your application.
Unless you call into a type contained within an AppDomain, it has no way to interact with your application.
So, if you have a dodgy third party DLL, or a DLL that you don't otherwise have the source code for, you can load it into an AppDomain to keep it isolated from your main application flow.
The end result is that if the third party DLL throws a wobbly, only the appdomain, and not your entire application is affected.