C# 大型项目的体系结构/文件设置（Visual Studio）

再来一次

目前，我们正在进行一个相当大的项目，我们已经召开了一些关于设计模式/架构/文件设置等的会议

在上次会议期间，我强烈反对提议的体系结构/文件设置，我不确定我是否只是为了它而漫无边际地争论我的观点

所以建议的是所有项目都位于一个SLN下，即数据、公共、业务和UI。显然，在一个小应用程序中，这将是非常好的，但考虑到这将是一个具有4-6个UI应用程序（所有web应用程序）的大型软件。 关于UI项目，将有一个核心UI（MVC）项目，在核心MVC应用程序使用区域内嵌套4-6个应用程序

我的问题是，如果dll坏了，它会把它全部搞坏。我建议的应用程序不会有这种影响，因为只有具有最新dll的应用程序才会失败

我也完全理解SLN是一个文件容器

同样，这并不是要诋毁我的任何同事，而更只是试图获得更广泛的知识

请看附件中的图片，请让我知道你的想法

问候,

---

Tez

一般来说，如果项目彼此不相关，那么它们应该位于单独的解决方案中。如果有多个exe项目共享大量代码，但它们自己依赖于许多（从三个到n个）未共享的项目，那么将它们分开是很有用的。在我看来，关于你是否应该把它们分开，没有一条金科玉律。最后，这取决于你应该自己评估的因素。就我个人而言，如果exe项目很复杂，我会将它们彼此分开，比如说它们是以MVVM风格构建的，当您为每个exe、视图dll、视图模型dll、模型dll都有一个引导程序时。如果你把它们放在同一溶液中，你的溶液可能会被严重污染。别忘了。sln合并。

公正评论。实际上，每个MVC应用程序都是一个部门。即运输、会计、营销等。。。它本质上依赖于少量的通用代码，但为该部门执行自己的一组操作，因此需要自己的解决方案/项目。（也许）那样的话，我会把它们分开。我看不出有任何理由将它们放在单一解决方案中。顺便说一句，在解决方案之间反复切换可能非常乏味。我的意思是，如果您的团队中有人打算参与所有这些项目，那么在这三种解决方案之间切换可能会变得非常困难。如果情况并非如此，则分别提出解决方案。还有其他想法/意见吗？