内部可重用库-作为DLL或项目重用?

这里有一些事情要考虑。

• 这些库为编译增加了多少额外的时间,您关心吗?
• 您需要多久修复一次其中的错误?

我使用预编译的库来处理任何几个月内不会改变的代码。如果我需要在一个包中每月更改一些代码超过一次,那么这个包就不会预编译。

我更喜欢预编译来加速主程序的编译。但我总是在预编译中包含调试符号,因此如果发生错误,我可以像其他程序集一样轻松地单步执行预编译程序集。

这真的取决于你是否是团队的负责人,如果你是团队的成员,将他们添加到你的源代码中,并在你执行任务时修复它们。如果您不在该团队中,请将其作为客户使用,并在发现缺陷时将其归档,否则您可能会对工作范围之外的代码负责。如果您处在一个灵活的环境中,这可能并不重要,但对我来说,这可能是一个问题突然成为代码更改的所有者,我没有发言权。

考虑到这一点的一个因素就是所说的库被重复使用的频率。如果他们倾向于在完全不同的项目中使用,你必须小心不要把自己画成一个角落,在那里你会发现你三周前为支持一些新的应用程序而对库所做的更改,结果却破坏了其他一些应用程序的更改。

基本上,我要说的是,你不想非得抵制这种诱惑,不情愿地对图书馆进行修改;最好不要把这种诱惑摆在你面前。如果库是为重用而设计的,那么对它的任何重大更改都应该非常仔细地设计和实现,并根据 全部的 依赖库/应用程序。当你真的把源代码放在面前,等待修改时,采取一种有纪律的方法会变得相当困难。

我的方法是创建 相关库 ;例如,我可能有一个用于核心接口和抽象类的程序集,一些用于不同具体实现的其他程序集,另一个用于单元测试,等等。如果存在依赖的可重用库层,那么它们通常都会集中到同一个解决方案中。

但它在应用程序级别停止。任何项目不是 总是 要与核心库一起部署并不共享解决方案,它只是引用已编译的dll。它强制我对库的更改进行规范,而不是为了支持某些特定的UI功能而开始对其进行调整。

我不知道这是不是“正确”的方法,但是我以前因为在没有正确测试依赖性的情况下过早地对库进行更改而被咬了一口,而且这总是由于过于关注单个应用程序而没有考虑到副作用。我的看法是,当你在图书馆工作时,你需要专注于 图书馆本身 而不是它在特定场景中的使用方式。

因为一个库是由多个独立的解决方案重用的,或者当库由另一个团队而不是使用它的团队管理时,我认为需要记住的最重要的规则是,解决方案的特定版本通常应该与该库的特定版本相关。

问问你自己:当我从六个月前签出解决方案的源代码时,我会得到哪个版本的库?如果答案是:总是图书馆的最新版本,这可能是有问题的。

我在一个项目中工作,开发人员自动在本地网络上发布他们的DLL的新版本。我们正在研究的解决方案刚刚引用了那个特定位置的DLL。问题在于,我们不知道自己编译的是哪个版本的库,在测试之后,我们发布了一个应用程序版本,因为突然发布了该库的新版本(我们没有测试)。

但是,当您重新开发应用程序的版本2时,它会变得更加明显,但是仍然需要维护应用程序的发布版本1。您希望使用最初发布时使用的同一个库版本发布版本1的补丁(当bug不在该库中时),否则您必须重新测试整个应用程序。

因此,我通常会添加我使用的所有库(默认情况下不在GAC中)作为解决方案的一部分,并将它们签入到源代码管理中。这样,我就可以完全控制解决方案在任何给定时间使用的版本。