MVC 文件夹结构与替代方案是否有充分的理由？

Question

在我使用过的大多数 MVC / MV* 类型框架中，他们希望您的源代码组织如下：

model/
    FooModel.xyz
    BarModel.xyz
view/
    FooView.xyz
    BarView.xyz
controller/
    FooController.xyz
    BarController.xyz

根据 MVC 元素而不是应用程序对象类型来组织目录。我的某些部分总是觉得如果代码是这样组织的，生活会更轻松：

Foo/
    FooModel.xyz
    FooView.xyz
    FooController.xyz
Bar/
    BarModel.xyz
    BarView.xyz
    BarController.xyz

因为一般来说，如果我正在处理 Foo（例如添加一个新字段），我经常会打开所有 Foo* 文件，这很乏味（第一世界问题），因为所有 Foo 文件都不同目录。

这是 Foo 源之间耦合太紧的代码味道吗？

当然，当我们的模型、视图或控制器没有相应的视图、控制器和模型时，这种替代方案的吸引力会降低。经常（通常？）是这种情况...

那么，为什么 MV* 框架的标准组织实际上比我提出的稻草人替代方案更好？

Answer 1

我自己也陷入了同样的困境。查看 StackOverflow，What strategy do you use for package naming in Java projects and why? 有一些有趣的见解，特别是 Uncle Bob's design principles for granularity。在通用重用原则中，他说：

包中的类一起重用。如果您重复使用其中一个 一个包中的类，你可以重用它们。

在你提到的设计包中，有一个model 包是非常有意义的，因为通过控制器和视图层重用多个模型类是很常见的。另一方面，foo 包很难像应用程序模块本身一样重用。另外，根据通用闭包原则：

包中的类应该一起关闭 变化的种类。影响软件包的更改会影响所有 该软件包中的课程。

与功能相关的更改（如更改 JavaScript 库或依赖注入框架）对model-view-controller 包（仅应更改一个包）的影响比对功能包（更改将涵盖所有包）的影响最小。

Answer 2

不确定其他 MVC 框架，但对于 ASP.NET MVC，视图应该位于 Views/ 文件夹中。

ASP.NET MVC 背后的原则之一是约定优于配置。视图引擎期望在某个位置找到视图。我相信您可以覆盖它，但通常最好不要这样做。 （使用约定）

我认为这种文件组织的最大问题是级联更改。如果我需要添加一个字段，我需要更新 5 个地方（模型、视图、视图模型、控制器、单元测试）。如果您在文件夹树中四处寻找这些东西，那可能会很乏味。

也许问题背后的问题是“如何更有效地浏览我的解决方案工件？”再次不确定其他 IDE，但由于我使用 Visual Studio，所以我有自己的一组偏好来帮助完成这项任务。

在 Visual Studio 中 ctrl+,（控制逗号）非常适合导航到解决方案中的类型/文件/工件。我还使用F12 和Shift+F12 来表示“转到定义”和“查找所有引用”。我还自定义了“在文件中查找”按钮以在工具栏中显示图像和文本，以使按钮更易于点击。