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

解决方案

回答

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

但是有时谨慎的做法是根据服务(如果我们使用的是面向服务的体系结构)(例如身份验证，销售等)进行分隔。

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

我个人认为，如果将可重用代码拆分为项目，则比仅在文件夹中使用其他位置更容易。

回答

丹妮写道：

I personally feel that if reusable code is split into projects it is simpler to use other places than if it is just in folders.

如果我们可以重用它，我真的同意，它应该在一个单独的项目中。话虽如此，要有效地重用也很困难:)

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

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

我不能代表所有人，但是我对我们保持它真正简化构建过程的简单程度感到满意！

回答

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

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

仅在以下情况下才有意义将源代码分成多个项目：

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

如果我们认为源代码的某些部分可以重用，请不要将其创建为新项目。只需等到我们真正想要在其他解决方案中重用它，然后根据需要将其与原始项目隔离开来。编程不是一件乐事，重用通常非常困难，而且通常不会按计划进行。

回答

Separating your source code into
  multiple projects makes only sense if
  you... 
  ... More developers involved
  and you want to treat their work as
  consumable black box. (not very
  recommended)  ...

为什么不建议这样做？我发现这是一个非常有用的方法，可以由多个在不同部分工作的开发人员管理应用程序。使签入更加容易，主要是通过消除合并来实现。很少有两个开发人员必须同时从事同一个项目。

回答

将特征分离到项目中通常是YAGNI架构优化。实际上，我们多久重复使用这些单独的项目？如果这种情况不经常发生，那么我们将使开发，构建，部署和维护变得复杂，以实现理论上的重用。

我更喜欢将其拆分为文件夹(使用适当的名称空间)，并在拥有真实的重用案例时进行重构以分离项目。

回答

如果确实要创建多个项目，请确保向解决方案添加代码的每个人都充分意识到他们的意图，并尽一切努力使他们了解项目之间的依赖关系。如果我们曾经尝试在某人走后清理混乱，并添加了不该去的参考资料并在数周之内摆脱了困境，那么我们将了解这一点

回答

我确实认为最好也拆分项目，但这完全取决于项目的规模和从事此项目的人数。

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

• 数据访问(模型)
• 服务
• 前端
• 测试

我是从Rob Connery和他的店面应用程序中获得的模型……似乎工作得很好。

mvc店面