Visual Studio大型解决方案

Question

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

我的问题是，为BE / BLL / DAL / Controls拥有多个项目是否很好，是否最好为BE / BLL / DAL层创建1个带有文件夹的项目？

Answer 1

“大”的问题是一个相对的问题。 在软件开发中，主要是您的PC的性能问题。 如果您可以在一秒钟内编译并运行100个项目，那么解决方案中的100个项目将“很小”。 因此，这实际上是一个对您有用的问题。

我当前的工作解决方案中包含约130个项目。 是的，我们可以突破，但是我们有一些令人印象深刻的盒子可以处理这个问题，因此拥有130个项目的成本适中至较低，而优势则要大于成本。

如果您可以快速编译，运行和测试所有项目，则可以将所有项目都集成在一个解决方案中。 Darn ...然后开始对话，讨论“ quick”是什么，这是一个风格问题。 如果您经常（每分钟或更快）编译和运行测试，那么快速就是几秒钟。 如果您每小时编译一次，那么几分钟就可以了。

答：“做对您有用的事情”。

注意：考虑解决方案文件夹。

Answer 2

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

Answer 3

据我了解您的问题，您指的是如何组织解决方案，而不是我如何更快地编写代码或如何使VS打开我的代码，代码查询器，对吗？

如果是这样，我想说的是，将解决方案中的类分解为多个项目，这些项目的名称应清楚说明其目的。 您已经使用示例“ BE / BLL / DAL / Controls”开始了类似的方法。

指定项目可以为您的解决方案体系结构提供很大的灵活性。 考虑一下您的解决方案随着时间的推移会增长多少，以及未来可能会使用多长时间。 考虑如何将其部署到最终用户，更重要的是，考虑如何部署更新。 所有这些考虑因素都将影响您做出详细决定的决策。

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

它是一种短期的，短期的工具，在开发过程中会运行几次，并且永远不会再次运行吗？ 那就不值得付出很多努力了。 它是需要维护几年的工具还是应用程序？ 然后，请确保已认真实施了SRP模式。

我推荐Microsoft出版社出版的这本书： 使用Windows Presentation Foundation和Model View ViewModel Pattern构建企业应用程序

这为您提供了有关如何构建良好的项目结构的一些建议，建议和基础。

关于如何构造解决方案的另一个建议是在以下SO线程中： Mvvm应用程序和业务层的位置