Model view controller MVC文件夹结构与备选方案是否有充分的理由？

在我使用过的大多数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*框架的标准组织实际上比我提出的草人替代方案更好呢

我自己也陷入了同样的困境。看看StackOverflow，有一些有趣的见解，特别是。在通用重用原则中，他说：

包中的类一起重用。如果您重用其中一个 在一个包中，可以重用所有类

在您提到的设计包中，拥有一个

模型

包非常有意义，因为通过控制器和视图层重用多个模型类是非常常见的。另一方面，

foo

包很难像应用程序模块本身一样重用。此外，根据通用闭合原理：

包中的类应按相同的顺序闭合在一起 各种变化。影响包的更改会影响所有 该包中的类

---

一些与技术相关的更改（如更改JavaScript库或依赖项注入框架）对

模型视图控制器

包（只有一个包应该更改）的影响比功能包（更改将覆盖所有包）的影响小。

不确定其他MVC框架，但是对于ASP.NET MVC来说，视图应该位于

views/

文件夹中

ASP.NET MVC背后的原则之一是约定优先于配置。视图引擎希望在特定位置找到视图。我相信你可以忽略这一点，但总的来说最好不要。（使用公约）

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

也许这个问题背后的问题是“我如何才能更有效地浏览我的解决方案工件？”同样不能确定其他IDE，但由于我使用Visual Studio，我有自己的一组首选项来帮助完成这项任务

---

在Visual Studio中，（控制逗号）非常适合导航到解决方案中的类型/文件/工件。此外，我使用

F12

和

Shift+F12

进行“转到定义”和“查找所有引用”。此外，我还定制了“在文件中查找”按钮，以便在工具栏中显示图像和文本，使按钮更容易点击。

除非某些框架的组织结构有技术原因，否则这感觉不是建设性的。但添加/删除/更改Foo元素的性质完全匹配“影响包的更改会影响该包中的所有类。“，这为替代布局提供了依据。这些类型的更改比更改依赖项要频繁得多。但作为一个模型元素，Foo预计会影响多个控制器和视图类。作为与应用程序域关联的模型，它预计会被其他几个组件使用。。。但我们仍然可以争论这些地点应该在哪里。同时，就IDE使其更容易而言，这不是一个坏主意。但它不能提供完整的答案，因为一般来说，您不应该有一个只适用于特定IDE的代码组织——项目中的其他开发人员可能希望使用不同的东西。像visualstudio这样的重量级ide当然有相反的观点，并且尽一切努力让它变得困难。。。