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包非常有意义，因为通过Controller和View Layers重用几个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来表示'goto definition'和'find all references'。我还自定义了“在文件中查找”按钮，在工具栏中显示图像和文本，使按钮更容易被击中。

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

2 个答案: