很多程序集都是坏的吗? [英] Are to many assemblies bad?
问题描述
我有一个小问题.在许多软件架构中,例如多层或类似企业库的东西,我在外部程序集中扩展了一些代码.有时,我的项目每个解决方案包含超过 20 个程序集.现在我很困惑...... 20 个程序集太多了吗?如果是,我可以在具有不同逻辑部分"的大型项目中做什么?如果我实现企业库,我通常最少有 5 个程序集.
I've one little question. In many software architectures, for example multi tier or something like the enterprise library, I expand some code in external assemblies. Sometimes my project includes more then 20 assemblies per solution. Now I'm confused... Are 20 assemblies to much? If yes, what I can do in a large project with different "sections" of logic? If i implement the enterprise library, I normaly have 5 assemblies minimally.
推荐答案
二十个程序集距离问题还有很长的路要走.只是为了比较,当我现在查看 Visual Studio 时,我看到它加载了 249 个程序集.VS 在我的机器上没有什么特别麻烦,它不会使用很多内存(现在 283 MB)并且在一两秒内启动.
Twenty assemblies is a long, long way from a problem. Just for comparison, when I look at Visual Studio right now, I see it having 249 assemblies loaded. Nothing particularly troublesome about VS on my machine, it does not use a lot of memory (283 MB right now) and starts up in a second or two.
CLR 通常不会花费大量资源来跟踪程序集.拥有大量它们的唯一可能缺点是它会影响程序的冷启动.如果您的程序初始化没有得到很好的优化(VS 被大量优化),并且如果您需要从慢速主轴驱动器运行,那么这 20 个组件可能会花费您一秒钟的时间.当然,只对交互式程序重要.ILMerge 将是一种解决方法.
The CLR does not spend heavy resources keeping track of assemblies in general. The only possible disadvantage of having a lot of them is that it can affect the cold-start of your program. And if your program initialization is not well optimized (VS was heavily optimized) and if you need to run from a slow spindle drive then those 20 assemblies can cost you a second worth of foot tapping. Only matters on interactive programs of course. ILMerge would be a workaround.
这篇关于很多程序集都是坏的吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!