我们开始开发新的应用程序,其中包括大约30个开发人员使用C#在MS Visual Studio中开发的30-50个项目.
我正在致力于组件化应用程序模块,以支持体系结构并实现并行工作.
我们争辩说:我们应该有多少解决方案？
有人声称我们应该有1-2个解决方案,每个解决方案有15-30个项目 有些人声称我们需要每个组件的解决方案,这意味着大约10-12个解决方案,每个解决方案大约3-6个
我很乐意听到每个方向(或其他方向)的优点/缺点和经验
谢谢
我在两个极端的产品上工作:一个在一个解决方案中有大约100个项目,一个有> 20个解决方案,每个包含4-5个项目(测试,业务层,API等).
每种方法都有其优点和缺点.
单个解决方案在进行更改时非常有用 - 它更容易使用依赖项,并允许重构工具正常工作.但是,它会导致更长的加载时间和更长的构建时间.
多个解决方案可以帮助实现关注点的分离,并使构建/加载时间保持在较低水平,并且可能非常适合让多个团队具有更窄的焦点和明确的服务边界.然而,它们确实在重构时有很大的缺点,因为许多引用都是文件,而不是项目引用.
也许混合方法的空间大部分都使用较小的解决方案,但是当需要进行更大规模的更改时,可以创建包含所有项目的单个项目.当然,你必须保持两个独立的解决方案......
最后,项目和依赖项的结构将对您组织解决方案的方式产生一些影响.
请记住,从长远来看RAM比程序员时间便宜......
解决方案确实存在于依赖关系管理中,因此如果多个方案取决于它,您可以在多个解决方案中使用项目.解决方案的数量应该取决于您的依赖关系图.
编辑:这意味着你不应该将不依赖于彼此的项目粘贴到同一个解决方案中,因为它会产生依赖的错觉,这意味着当两个项目真正独立时,有人可以创建一个真正的依赖.
我已经研究了近200个项目的解决方案.如果你有足够的RAM :)这不是什么大问题.
要记住的一件重要事情是项目依赖于彼此(无论是依赖关系还是引用),它们应该在同一个解决方案中.否则,当不同的项目在不同的解决方案中具有不同的依赖关系
京公网安备 11010802040832号 | 京ICP备19059560号-6 