logo标签列表

Visual Studio大型解决方案

c#visual-studio
5

我有一个包含近12个项目和3个网站的Web应用程序解决方案。 有些项目被用于多个网站，例如MyProject.BE / MyProject.BLL / MyProject.DAL / MyProject.Controls 项目。

我的问题是，将BE / BLL / DAL / Controls分成多个项目还是创建1个带有BE / BLL / DAL层文件夹的项目更好？

如果你把它们合并成一个，你将如何在其他地方引用它？当前的方式似乎不错，但这是实际的问题吗？ - V4Vendetta
4
“almost 12 projects” 的意思是 “几乎有12个项目”，也就是说有11个项目。 - O. R. Mapper
2
多个项目是完全可以的。我曾经处理过大约60个项目的解决方案。 - Leon Cullens
@Ruutert 嗯，性能稍微有所降低，但并未注意到实质性的差异。主要是 VS 的启动时间比较慢，但通常你只需要启动一次 VS，然后在整天内保持打开状态。 - Leon Cullens
也许我错了，但是在较少的项目中有更多的代码并不会使您的构建速度更快。 - Dave New
显示剩余3条评论
3个回答
6
“大”是一个相对的问题。在软件开发中，这主要取决于你的电脑有多好。如果您可以在1秒内编译和运行100个项目，则解决方案中的100个项目就是“小”的。所以真正的问题是什么适合你。
我的当前工作解决方案中有大约130个项目。是的，我们可以将其拆分，但是我们有一些强大的盒子可以处理这些，因此拥有130个项目的成本是中等到低，并且优点比成本更高。
如果您可以快速编译、运行和测试所有项目，则将所有项目放在一个解决方案中是最好的选择。那么这会引起“快速”的讨论，这是一个风格问题。如果您经常（每分钟或更快）编译并运行测试，则几秒钟就可以完成。如果您每小时或更长时间才编译和运行，则几分钟就可以了。
回答：“做适合自己的事情”。
注意：考虑解决方案文件夹。
1
我的上一家公司在一个解决方案中有超过350个项目。其中大部分项目都是类库，被其他项目引用。虽然这个解决方案有350个项目，但这并不意味着它是一个庞大的解决方案。由于每个项目的复杂性和代码量，它是一个庞大的解决方案。正如Rob Smyth所说，这是相对的。我们发现构建整个解决方案是危险的，因此我们只构建了必须的项目。也就是说，我们只构建了我们已经进行更改的项目。 - zeencat
+1 感谢帮助找出“大型”解决方案，也感谢文件夹使用建议。 - Larry
你所说的“好电脑”，主要是指内存（大小和速度）吗？还是硬盘访问速度更重要？ - mlhDev
嗨，马修。我想你在问如何加速计算机的主要问题。如果是这样...我无法回答。如果您关心电脑的性能，请监视内存使用率、CPU等，并调整到接近或达到其极限的状态。根据我的经验，内存使用率应该小于50％，总CPU通常应该小于20％。但是这已经超出了我的技能范围。FYI：我提到的快速机器有（从记忆中）32GB RAM，两个SDD（一个用于操作系统，另一个用于数据），以及I7 CPU。如果您需要证明成本，您需要记录编译等时间。 - Rob Smyth
0

我认为拥有多个项目确实更好。例如，如果您需要构建一个WinForms UI，它将使用BE和DAL层中某些现有类，那么您只需从WinForms项目引用这些项目即可。

0

就我所理解的问题而言，您是在询问如何组织解决方案，而不是如何使编译代码更快或如何使VS更快地打开我的代码，对吗？

如果是这样，我建议将解决方案中的类分解为多个项目，并使用能清楚表明其目的的名称。您已经开始采用“BE/BLL/DAL/Controls”示例的方法。

指定项目可以为解决方案架构提供很大的灵活性。考虑一下您的解决方案可能随着时间的推移而增长的程度以及它在未来的生命周期有多长。考虑一下您将如何将其部署到最终用户以及更重要的是，您将如何部署更新。所有这些考虑因素都应影响您决定要深入细节的程度。

分析您的代码并检查是否有潜力应用经过时间验证的设计模式，例如单一职责原则。

它是一个短期且仅在开发过程中运行几次的工具吗？那么它不值得花费太多精力。它是需要维护几年的工具或应用程序吗？那么请确保仔细实施SRP模式。

我推荐这本由微软出版社出版的书籍: Windows Presentation Foundation和Model View ViewModel Pattern构建企业应用程序 这本书会给你提供一些关于如何构建良好项目结构的建议、推荐和基础知识。
另一个建议是在这个SO主题中展示的解决方案结构：Mvvm应用程序和业务层位置。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接