.net - .NET 中分离项目/DLL 的优缺点？其中有多少是太多了？

Question

这个问题涉及一些其他相关的问题，我只是把每一个问题都扔在上面，随意回答一个或多个。

分离 Projects/DLL 有什么好处？

分离 Projects/DLL 的缺点是什么？

如果我为每个可共享资源创建一个新的解决方案/DLL，会不会有很多项目？

在过多的项目(如 40 多个)之后，这会对 IDE 性能(VS.NET 2008)产生一些不良影响吗？

我问这个问题是因为我有这么多不同类的大解决方案，因为现在我需要分离一些接口(interface)，它都分崩离析( 循环依赖 问题)，现在我需要创建多个DLL，我只是想确保这次以正确的方式进行。

Answer 1

关于论点的范围，这个问题的答案可能很长，我认为首先最好关注什么是 choiches 以及需要在多个程序集中分离项目的原因，一般来说，这可能是一般设计和分层和/或清理项目结构。

1.分离Solutions/DLL有什么好处？

分离解决方案和组件的优势通常与设计方法、代码重用和层组织有关，如上所述，分离解决方案有助于共享对象/组件并在层之间分配责任，促进多目标和可插拔解决方案(参见例如各种存储目标程序集(数据库、文件等))、可测试性

2. 分离Solutions/DLL有什么缺点？

正如其他人在我之前所说的那样，主要缺点首先是复杂性(管理，维护)，然后是性能(但这是另一个讨论，说起来并不容易)

3. 如果我为每个可共享的资源创建一个新的解决方案/DLL 会不会有很多解决方案？

这取决于，首先我认为这可能取决于设计选择

4. 在解决方案过多(如 40+)之后，这会对 IDE 性能(VS.NET 2008)产生一些不良影响吗？

我不太确定 VS2008 IDE 中的性能下降，但可以肯定的是，管理 60 多个项目的单个解决方案可能会影响性能，而不是例如每个 20 个项目的 4 个解决方案。
必须清楚的是，即使在仅从单个或双项目解决方案中打开例如 35 个文件之后，VS IDE 性能也可能会下降。

最后，我认为我要记住的重要一点是，最好“构建”它真正需要的东西，而不是陷入过度设计，所以当事情变得太复杂而无法管理(对于许多项目)时，它会更好停下来想“一切顺利？”