具有许多DLL的应用程序是一件坏事吗？

Question

我们有一个enterpise Web应用程序,它由4个编译组件(DLL)组成.一年多以前,我们开始实现更细粒度的组件,以试图隔离功能,减少耦合并降低重新编译和部署大量代码的风险.虽然没有人认为这种方法在添加新功能和修补错误时为我们提供了更多灵活性和上市速度,但现在应用程序包含近40个dll.我们有一个命名约定,可以很好地识别我们的组件.

我的问题是:有多个dll的应用程序是否存在任何漏洞(性能,维护等)？

编辑:我们正在探索将代码重构为更大的组件的选项,我认为这可能是各种各样的回归......

Answer 1

我的问题是:有多个dll的应用程序是否存在任何漏洞(性能,维护等)？

有许多DLL的缺点？没有
DLL太多的缺点？当然.

那么多少太多了？

程序集是一种组织方式,如命名空间和类.命名空间定义逻辑边界,程序集物理边界.

您应该尝试保持程序集一致,并将它们视为系统模块.

是的,如果你有数百个,那么就会出现(小)性能问题.但是有了40,我没有看到问题.

Answer 2

将独立的功能域分成单独的DLL通常是一件好事.它有助于引入重用的可能性,并有助于减少类的内部实现之间引入不适当的耦合.

但是,将多个程序集作为系统的一部分引入有一些缺点:

1. 加载,验证和JIT多个程序集需要更长的时间.然而,这很少是一个问题 - 在决定如何对应用程序的功能进行分区时,通常不应该首先考虑这个问题.
2. 通过在单个程序集中部署更改来更新应用程序可能是不明智的.通常将应用程序划分为单独的DLL会产生一种印象,即可以通过替换它的一些程序集来修复或增强它.虽然如果这些程序集中的类和方法的副作用或未记录的行为发生变化,它肯定会引入细微的错误.
3. 理解分成太多组件的系统可能更难.在分析跨多个程序集划分的代码时,ReSharper和CodeRush等工具有一些限制.
4. 它可以鼓励开发人员公开更多类型的公开.由于只有公共类型可以被其他程序集使用和继承,因此多组件项目可能会导致更多的公共类型.

Answer 3

维护 - 不,性能 - 是的.需要加载的程序集越多,应用程序启动的速度就越慢.对于需要加载到AppDomain的每个程序集,加载程序需要执行一系列验证.

Answer 4

The sorts of issues that get worse with more DLLs are:

• Build times: the compiler runs once for each DLL, and DLLs must be copied to and from the output directory
• Load times: each DLL file must be loaded separately by Windows, although DLLs are demand loaded, so you will typically incur cost for only the parts you use
• Rebasing: the more DLLs you have, the greater the chance that two will collide in virtual memory. This doesn't pose a problem, because Windows can rebase one of them, but the rebasing process takes time, and Windows must load any affected DLL pages from disk in advance. Rebasing doesn't typically affect managed DLLs much.
• Visual Studio overhead: one DLL = one project = more work for the IDE

The advice I follow is to use DLLs to organise your deployment, and namespaces to organise your code. If you find that you always release a given set of DLLs together, you might as well merge them.