4

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

4

2 回答 2

1

我自己也陷入了同样的困境。查看 StackOverflow，您在 Java 项目中使用什么策略来命名包，为什么？有一些有趣的见解，特别是 Bob 大叔的粒度设计原则。在通用重用原则中，他说：

包中的类可以一起重用。如果你重用一个包中的一个类，你就重用它们。

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

一个包中的类应该一起关闭以防止相同类型的更改。影响软件包的更改会影响该软件包中的所有类。

一些与技术相关的更改——比如更改 JavaScript 库或依赖注入框架——对model-view-controller包的影响（只有一个包应该更改）比功能性的影响最小（更改将跨越所有包）。

于 2013-01-28T19:42:13.080 回答
1

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

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

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

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

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

于 2013-01-28T20:07:00.507 回答