具有许多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

随着更多DLL而变得更糟的问题是：

• 构建时间：编译器为每个DLL运行一次，并且必须在输出目录中复制DLL
• 加载时间：每个DLL文件必须由Windows单独加载，尽管DLL是需求加载的，因此通常只会为您使用的部分产生费用
• 重新映射：您拥有的DLL越多，两者在虚拟内存中发生碰撞的可能性就越大。这不会造成问题，因为Windows可以重新绑定其中一个，但是重新定位过程需要时间，Windows必须提前从磁盘加载任何受影响的DLL页面。重新绑定通常不会对托管DLL造成太大影响。
• Visual Studio开销：一个DLL =一个项目= IDE的更多工作

我遵循的建议是使用DLL来组织部署，使用命名空间来组织代码。如果您发现总是将一组给定的DLL一起发布，那么您也可以合并它们。

Answer 5

不要忘记ILMerge。如果你想要多个DLL用于开发（不同的项目），但是需要一个EXE用于部署（加载速度更快，更易于部署），它的效果非常好。

ILMerge的缺点是它会在某些动态加载方案中失败，例如，通过（字符串）名称创建类型的实例。因此，ILMerge可能或可能不可行，具体取决于您的IoC提供商。