.net – 数百个项目是危险的还是笨重的解决方案?

我们的主要客户解决方案有111个项目当我第一次开始这个团队时,我很惊讶(并且惊慌失措)我们有很多项目,并建议将这些层级整合到更少但更大的组件中.我们的结构具有带有nhibernate映射文件的模型(DTO),带有数据控制器调用的WCF服务层,一些框架类型项目以及具有多个模块的winform CAB应用程序.我们将使用点击一次部署.

由于构建时间(最差情况下最多15分钟),其他一些团队成员现在也担心.我没有经验证据表明较少的项目是一个好主意,并且想知道堆栈溢出社区是否有任何反馈.是否有令人信服的理由改变我们的解决方案结构来整合项目?我们会遇到使用click-once部署100个程序集的麻烦吗?加载和调用方法调用时,更多的程序集会导致缓慢吗?我们可能遇到的任何限制可能会破坏事情?

在单个解决方案中包含许多项目的最大问题(特别是当项目之间存在许多相互依赖关系时)是编译时间会快速减慢.我看到当项目数量增长时,编译时间会持续几分钟到几十分钟.

如果需要加载和初始化100个组件,应用程序启动也会受到影响.当然,这假定应用程序需要所有100个程序集.

如此众多的项目也暗示了代码组织的问题.我会称这是一个明确的代码味道.它看起来像是一种超越合理的脱钩尝试 – 一种建筑宇航员的想法.

我不担心部署故事,因为将一个程序集部署到一个目录中与将100部署到一个目录没有太大区别……当然,通过Web部署100个程序集将会更慢(100个连接而不是1个,可能是有更大的尺寸……).

有些工具可以合并多个程序集,这可以帮助解决这个问题 – 最着名的是Microsoft – ILMerge.

在进行部署时需要担心的一个更大的问题是配置并使其正确,特别是如果大多数程序集需要自己的配置.

相关文章
相关标签/搜索