我看到并完成了很多小型产品,其中同一块软件被分成一个可执行文件和几个DLL,而这些DLL不仅仅是由其他人完成的共享库,而是库这是由同一个开发团队专门为此软件完成的。 (我不是在这里谈论大型产品,它只需要数百个DLL并与其他产品广泛分享。)
我理解将代码分成几个部分,每个部分都编译成一个单独的DLL,从开发人员的角度来看是好的。这意味着:
但最终用户怎么样?提供由一个EXE和EXE组成的软件并不是一件坏事。几个DLL,什么时候可以组合在一起?毕竟:
从最终用户的角度来看,是不是更好,对于中小型程序来说,提供一个大的可执行文件?如果是这样,为什么没有工具可以轻松实现(例如,一个集成在通用IDE中的魔术工具,它将整个解决方案编译成一个可执行文件,当然不是每次,但是按需或在部署期间。
这与用户的putting all CSS or all JavaScript files into one big file类似。拥有多个文件对于开发人员来说更加智能,并且更易于维护,但是将网站的每个页面链接到两个文件而不是几个文件可以优化性能。以同样的方式,CSS sprites对设计师来说很糟糕,因为他们需要更多的工作,但从用户的角度来看更好。
答案 0 :(得分:8)
这是一种权衡
(你已经把它想出来了;))
对于大多数项目,客户并不关心安装了多少文件,但他关心的是有多少功能及时完成。让开发人员的生活更轻松也有利于用户。
DLL的更多原因
某些库在同一版本中不能很好地协同工作,但可以在DLL中运行(例如,一个DLL可能使用WTL3,另一个需要WTL8)。
某些DLL可能包含要加载到其他可执行文件中的组件(全局挂钩,shell扩展,浏览器插件)。
某些DLL可能是第三方,仅作为DLL提供。
公司内部可能会重复使用 - 即使您只看到一个“公共”产品,也可能会在使用该DLL的十几个内部项目中使用它。
某些DLL可能是使用不适用于公司所有开发人员的不同环境构建的。
独立EXE与已安装产品
无论如何,许多产品不能作为独立的可执行文件工作。它们需要安装,用户不要接触他不应该触摸的东西。拥有一个或多个二进制文件并不重要。
构建时间影响
也许您低估了构建时间的影响,并为大型项目维护稳定的构建。如果构建需要甚至5分钟,你可以用化学方式称“让开发人员提前思考,而不是修补,直到看起来工作正常”。但这是一个严肃的时间,并造成严重的分心。
单个项目的构建时间很难改善。在VC9上工作,在一个项目中构建并行化是不稳定的,增量链接器也是如此。链接时间特别难以通过更快的机器“优化”。
开发者独立
另一件你可能会低估的事情
要使用DLL,您需要.dll和.h。
要编译和链接源代码,通常需要设置包含目录,输出目录,安装第三方库等。真的很痛苦。
答案 1 :(得分:1)
是的,这是更好的恕我直言 - 我总是使用静态链接,正是你给出的理由,只要有可能。发明动态链接(例如,节省内存)的许多原因不再适用。 OTOH,有架构原因,例如插件架构,为什么动态链接可能比静态更好。
答案 2 :(得分:0)
我认为您关于仔细考虑可交付成果的最终包装的一般观点是很好的。在JavaScript的情况下,这样的包装确实是可能的,并且通过压缩产生了显着的差异。
答案 3 :(得分:0)
完成了很多项目,从未遇到过最终用户,这些最终用户对他的盒子上的一些dll文件有任何问题。
作为开发者,我会说是的,这很重要。作为关心的最终用户......
答案 4 :(得分:0)
是的,从最终用户的角度来看,它往往会更好。但是,您提到的开发人员(和开发过程)的好处通常意味着企业会更喜欢具有成本效益的选择。
这是一个功能太少的用户会欣赏,这将花费非常微不足道的数量。
请记住,StackOverflow上的用户是“高于平均水平”的用户。你有多少(非极客)家庭成员和朋友真的重视将软件安装到USB记忆棒的能力?
答案 5 :(得分:0)
dll的巨大优势与边界和独立性的引入有关。
例如,在C / C ++中,只有导出的符号可见。想象一下,一个模块A带有一个全局变量“scale”,另一个模块B带有另一个全局变量“scale”,如果你把所有的变量放在一起就是desaster;在这种情况下,dll可以帮助你。
您可以将这些dll作为组件分发给客户,而不需要完全相同的编译器/链接器选项;这通常是进行跨语言互操作的好方法。