将解决方案拆分为逻辑层时，何时最好使用单独的项目而不是仅按文件夹分组？
问问题
4626 次
7 回答
17
默认情况下，总是在同一个项目中创建新文件夹
- 您将获得单个组件（无需额外的 ILMerge 体操）
- 更容易混淆（因为您将拥有更少的公共类型和方法，理想情况下根本没有）
将源代码分成多个项目只有在您...
- 将源代码的某些部分作为项目的一部分，但默认情况下或根本不可部署（单元测试、额外插件等）
- 更多的开发人员参与其中，您希望将他们的工作视为可消耗的黑匣子。（不太推荐）
- 如果您可以清楚地将您的项目分成独立的层/模块，并且您想确保它们不能交叉使用内部成员。（也不推荐，因为您需要决定哪个方面最重要）
如果您认为源代码的某些部分可以重用，仍然不要将其创建为新项目。等到您真的想在另一个解决方案中重用它并根据需要将其从原始项目中隔离出来。编程不是乐高积木，重用通常非常困难，而且通常不会按计划进行。
于 2008-08-04T22:45:32.940 回答
7
丹尼写道：
我个人觉得，如果将可重用代码拆分到项目中，那么在其他地方使用比仅在文件夹中更简单。
我真的同意这一点——如果你可以重复使用它，它应该在一个单独的项目中。话虽如此，有效重用也非常困难:)
在 SO，我们试图通过三个项目变得非常简单：
- MVC Web 项目（默认情况下，它很好地将您的图层分隔到文件夹中）
- 用于我们数据库源代码控制的数据库项目
- 针对 MVC 模型/控制器的单元测试
我不能代表所有人，但我很高兴我们保持它的简单性 - 真的加快了构建速度！
于 2008-08-04T22:42:55.067 回答
7
将功能分离到项目中通常是 YAGNI 架构优化。你有多少次重复使用这些单独的项目，真的吗？如果这种情况不经常发生，那么您就会使开发、构建、部署和维护复杂化，以实现理论上的重用。
当你有一个真实的重用用例时，我更喜欢分成文件夹（使用适当的命名空间）并重构为单独的项目。
于 2008-08-17T17:35:22.070 回答
4
我通常为 GUI 做一个项目，为业务逻辑做一个项目，为数据访问做一个项目，为单元测试做一个项目。
但有时基于服务（如果您使用面向服务的架构）进行分离是明智的，例如身份验证、销售等。
我想我工作的经验法则是，如果您可以将其视为具有明确分离关注点的组件，那么另一个项目可能是谨慎的。但我认为文件夹与项目可能只是一种偏好或理念。
我个人觉得，如果将可重用代码拆分到项目中，那么在其他地方使用比仅在文件夹中更简单。
于 2008-08-04T22:14:17.310 回答
1
我真的认为最好还是拆分项目，但这完全取决于项目的规模和参与项目的人数。
对于较大的项目，我有一个项目
- 数据访问（模型）
- 服务
- 前端
- 测试
我从 Rob Connery 和他的店面应用程序那里得到了模型……似乎工作得很好。
于 2008-09-15T23:45:06.280 回答
0
将源代码分成多个项目只有在您... ... 更多开发人员参与并且您希望将他们的工作视为可消耗的黑匣子时才有意义。（不太推荐）...
为什么不推荐这个？我发现这是一种非常有用的方法来管理一个应用程序，其中有几个开发人员在不同的部分工作。主要通过几乎消除合并使签入变得更加容易。很少有两个开发人员必须同时处理同一个项目。
于 2008-08-17T17:19:51.993 回答
0
如果您确实要创建多个项目，请确保将代码添加到解决方案的每个人都完全了解它们的意图，并尽一切可能让他们了解项目之间的依赖关系。如果您曾经尝试在有人离开并添加不应该存在的参考文献并在几周内侥幸逃脱的情况下整理混乱，您就会理解这一点
于 2008-09-10T21:36:06.883 回答