Visual Studio 解决方案中的文件夹或项目？ [关闭]

Question

关闭。 这个问题是基于意见的。 它目前不接受答案。

---

想改善这个问题吗？ 更新问题，以便通过编辑这篇文章用事实和引文来回答问题。

2年前关闭。

改进这个问题

将解决方案拆分为逻辑层时，何时最好使用单独的项目而不是仅按文件夹分组？

Answer 1

默认情况下，始终只在同一个项目中创建新文件夹

• 您将获得单个组装（无需额外的 ILMerge 体操）
• 更容易混淆（因为您将拥有更少的公共类型和方法，理想情况下根本没有）

将源代码分成多个项目只有在您...

• 将源代码的某些部分作为项目的一部分，但默认情况下或根本无法部署（单元测试、额外插件等）
• 更多的开发人员参与，并且您希望将他们的工作视为可消耗的黑匣子。 （不是很推荐）
• 如果您可以清楚地将您的项目分成隔离的层/模块，并且您想确保它们不能交叉使用内部成员。 （也不推荐，因为您需要决定哪个方面最重要）

如果您认为源代码的某些部分可以重用，仍然不要将其创建为新项目。 等到您真的想在另一个解决方案中重用它并根据需要将其从原始项目中分离出来。 编程不是乐高积木，重用通常非常困难，而且通常不会按计划进行。

Answer 2

将功能分离到项目中通常是 YAGNI 架构优化。 你重复使用这些单独的项目的频率是多少，真的吗？ 如果它不是经常发生，那么您正在使开发、构建、部署和维护复杂化，以实现理论上的重用。

我更喜欢分成文件夹（使用适当的命名空间）并在您有现实生活中的重用用例时重构以分离项目。

Answer 3

丹尼写道：

我个人觉得，如果将可重用代码拆分到项目中，那么在其他地方使用比仅在文件夹中使用更简单。

我真的同意这一点 - 如果你可以重用它，它应该在一个单独的项目中。 话虽如此，有效地重用也非常困难:)

在 SO，我们试图通过三个项目非常简单：

• MVC Web 项目（默认情况下，它可以很好地将图层分隔到文件夹中）
• 用于我们数据库源代码控制的数据库项目
• 针对 MVC 模型/控制器的单元测试

我不能代表所有人，但我很高兴我们保持它的简单性 - 真正加快了构建速度！

Answer 4

我通常做一个 GUI 项目、业务逻辑项目、数据访问项目和单元测试项目。

但有时基于服务（如果您使用面向服务的架构）（例如身份验证、销售等）进行分离是明智的。

我想我工作的经验法则是，如果你可以将它视为一个具有明确关注点分离的组件，那么不同的项目可能是谨慎的。 但我认为文件夹与项目可能只是一种偏好或理念。

我个人觉得，如果将可重用代码拆分到项目中，那么在其他地方使用比仅在文件夹中使用更简单。

Answer 5

我真的认为最好也拆分项目，但这一切都取决于项目的规模和从事该项目的人数。

对于较大的项目，我有一个项目

• 数据访问（模型）
• 服务
• 前端
• 测试

我从 Rob Connery 和他的店面应用程序那里得到了模型......似乎工作得很好。

mvc-店面

Answer 6

将您的源代码分成多个项目只有在您......更多开发人员参与并且您希望将他们的工作视为可消耗的黑匣子时才有意义。 （不是很推荐）...

为什么不推荐这个？ 我发现这是一种管理应用程序的非常有用的方法，其中多个开发人员在不同的部分工作。 使签入更容易，主要是通过几乎消除合并。 很少有两个开发人员必须同时在同一个项目上工作。

Answer 7

如果您确实要创建多个项目，请确保向解决方案添加代码的每个人都完全了解他们的意图，并尽一切努力让他们了解项目之间的依赖关系。 如果您曾经尝试过在某人离开并添加不应该存在的引用并在数周内逍遥法外时理清一团糟，那么您就会明白这一点