复制粘贴与引用

Question

我的问题是关于引用开源框架。它们中有许多是出于许多不同的目的。我个人在一个项目中使用了其中的几个。例如：

1. Unity
2. CAL/Prism
3. ValidationAspects
4. EnterpriseLibrary Logging
5. EnterpriseLibrary异常Handling
6. EnterpriseLibrary Caching
7. Caliburn

从开发工作的角度来看，所有这些框架都有很大帮助。然而，也有一些消极的方面：

list).

• Application的

1. Tons (15来自以上的级别(非公共程序集和新程序集)必须引用许多核心dll，这可能会让人感到困惑)，而数吨不同的名称空间都可能会出现问题(我有时使用ILMerge来缓解这个问题和上面的问题，但暂时搁置一下)。
   1. 开放源码项目生存期--开源项目的来来去去，所以如果其中任何一个不再被积极维护，它可能是关心的，如果有内部的错误，需要修复或增强，我们want.
   2. Obfuscation的“如何做事情”。我们并不积极地利用上述框架的每个部分。事实上，这些框架中有几个是重叠的，提供了冗余的组件和功能。就发展而言，这可能令人困惑。我们希望在我们的代码库中实现一个简单易懂的一致实现。在这方面，拥有多个以不同方式做同一件事的区域可能会很麻烦。如果这些框架引用其他程序集的不同版本(即，)，这可能是我最大的麻烦之一。一个内部引用Unity1.1，另一个引用Unity2.0).

另一种选择？将源代码包含在项目的公共dll中(即。MyProject.Common)。让我们暂时搁置遵守许可要求的问题。

这也有一些负面影响：

要利用框架提供程序发布的更新并不容易--您需要更新源代码的功能code.

• Encapsulation --当源代码全部掌握在您手中时，更容易打破这种模式。

所以，我知道人们可能对this...and有很多意见，我想听听他们。

谢谢。

Answer 1

对于问题的某些方面，这可能是相关的：http://en.wikipedia.org/wiki/DLL_hell#Running_Conflicting_DLLs_Simultaneously。

解决此问题的另一个常见解决方案是在所需功能的基础上编写封装层，这至少可以保护代码在升级到支持库的新版本时不受任意更改。

至于开源项目的生存期，应该清楚哪些项目是健康的，哪些项目不健康。例如，作为Apache或Eclipse基础的一部分的项目可能是健康的，而sourceforge上的一些随机的东西可能并不健康。通常，您可以通过避免看起来不活跃的项目来完全避免这个问题。

对于将代码复制到项目中的负面因素：

1. 我知道你想把许可证放在一边，但实际上你不能。我不是律师，如果可能有问题，您应该为您的项目咨询一位律师，但是如果您正在开发一个专有系统，它可能会成为GPL‘’ed accidentally.
2. It，使您的开发环境更加混乱。您必须确保复制的代码堆正确，正在用正确的版本编译，并有正确的构建脚本。您的IDE中还有占用空间的所有额外代码。正如您所指出的，
3. 使更新代码变得非常困难。
4. --如果您必须向开放源码项目中提交bug，就会变得更加困难。
5. 如果你不小心的话，一个不太懂的初级开发人员可以进入代码并开始处理它.

也许有更多的理由不这样做，但这是少数。希望这能有所帮助。