5

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

我的问题是，为 BE/BLL/DAL/Controls 创建多个项目是否更好，或者为 BE/BLL/DAL 层创建一个带有文件夹的项目是否更好？

4

3 回答 3

6

“大”的问题是一个相对的问题。在软件开发中，主要是您的 PC 有多好的问题。如果您可以在 1 秒内编译和运行 100 个项目，那么解决方案中的 100 个项目是“小”的。所以这真的是一个对你有用的问题。

我目前的工作解决方案中有大约 130 个项目。是的，我们可以打破它，但我们有一些令人印象深刻的盒子可以处理这个问题，因此拥有 130 个项目的成本适中到低，优势比成本更大。

如果您可以快速编译、运行和测试它们，那么将所有项目都放在一个解决方案中是可行的。该死的......然后开始讨论什么是“快速”，这是一个风格问题。如果您经常（每分钟或更快）编译和运行测试，那么快就是几秒钟。如果您每隔一小时左右编译和运行一次，那么几分钟就可以了。

答：“做对你有用的事”。

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

于 2012-06-25T11:04:59.280 回答
0

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

于 2012-06-25T11:09:23.907 回答
0

据我了解您的问题，您指的是如何组织解决方案，而不是如何更快地编译代码或如何制作 VS-open-my-代码更快，对吧？

如果是这样，我会说，将解决方案中的类分解为多个项目，其名称清楚地表明它们的用途。您已经通过您提供的“BE/BLL/DAL/Controls”示例开始了类似的方法。

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

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

它是一个短期的短期工具，在开发过程中运行了几次，然后就再也没有了？那么这将不值得付出太多努力。它是需要维护几年的工具或应用程序吗？然后去确认 SRP 模式是经过仔细实现的。

我推荐微软出版社的这本书：Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern

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

关于如何构建解决方案的另一个建议是在这个 SO 线程中：Mvvm Applications And location of Business layer

于 2012-06-25T11:30:43.677 回答