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

默认情况下, 总是只创建新文件夹 在同一个项目中

• 你将得到一个集合(没有额外的ilmerge体操)
• 更容易混淆(因为您将拥有较少的公共类型和方法,理想情况下完全没有)

只有当你……

• 源代码的某些部分是项目的一部分,但默认情况下或根本不可部署(单元测试、额外插件等)。
• 更多的开发人员参与进来,您希望将他们的工作视为可消费的黑盒。(不太推荐)
• 如果你能将你的项目清晰地分成独立的层/模块,并且你想确保它们不能交叉使用 内部的 成员。(也不推荐,因为您需要决定哪个方面最重要)

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

将特性分离到项目中通常是一种雅格尼体系结构优化。实际上,您多久重复使用这些单独的项目一次?如果这不是一个经常发生的事情,那么您将使开发、构建、部署和维护复杂化,以实现理论上的重用。

我更喜欢将它们分成文件夹(使用适当的名称空间)并重构,以便在实际的重用用例中分离项目。

丹尼写道:

我个人认为,如果将可重用代码拆分为项目,那么使用其他位置比只在文件夹中更简单。

我真的同意这一点——如果您可以重用它,它应该在一个单独的项目中。也就是说,很难有效地重用:)

在这里,我们试着用三个项目做到非常简单:

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

我不能代表每个人发言,但我很高兴我们保持了它的简单-真的加速了建设!

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

但有时,谨慎的做法是基于服务(如果您使用面向服务的体系结构)进行分离,例如身份验证、销售等。

我想我得出的经验法则是,如果您可以将它看作是一个具有清晰关注点分离的组件,那么另一个项目可能是谨慎的。但我认为文件夹和项目可能只是一种偏好或理念。

我个人认为,如果将可重用代码拆分为项目,那么使用其他位置比只在文件夹中更简单。

将源代码拆分为 多个项目只有在 你… …更多开发人员参与 你想把他们的工作当作 消耗品黑匣子。(不是很) 建议使用…。

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

如果您确实要创建多个项目,请确保向解决方案添加代码的每个人都充分了解它们的意图,并尽一切可能让他们了解项目之间的依赖关系。如果你曾经尝试过在某人离开时解决混乱,并添加不应该出现的参考资料,并在几个星期内摆脱它,你就会明白这一点。

我真的认为分割项目也更好,但这一切都取决于项目的规模和从事这项工作的人数。

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

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

我从Rob Connery那里拿到了模型和他的店面申请表…似乎工作得很好。

mvc-storefront