11

一段时间以来，我一直在为如何使用 MVC 框架重新编码基于页面的 PHP 应用程序而苦苦挣扎。仅作为背景，我不得不将应用程序移至 MVC，因为我的老板正在制作我。不管怎样，我坐下来，打印出目录结构。然后我开始尝试计划如何将这些页面转换为控制器/动作对。有些事情看起来很直接。例如，我有几个页面专门用于添加/编辑/删除用户。这很容易创建一个“用户”控制器，并为添加/编辑/删除添加方法或操作。我遇到的问题是决定何时实际创建控制器而不是仅将某些东西作为动作，因为它并不总是那么明确。例如，登录控制器与用户/登录，或注册控制器与用户/注册。大部头书，

另一个例子是，我有大约 12 个用于创建“计划”的表单页面。在我的脑海中，我认为我需要创建一个“计划”控制器，然后每个旧的页面都会变成一个动作。所以我有一个控制器，有 12 个动作（方法）。对我来说，问题是，尽管所有 12 个页面都是数据输入表单，但最终构成了这个“计划”，这就是它们的共同点。每个页面使用数据库中的不同表，并且彼此之间没有任何共同之处。基本上通过创建一个“计划”控制器，我只是将其用作分组机制；不一定要使用它，因为它们彼此相关。至少在上面的“用户”控制器示例中；这些动作中的每一个都使用相同的“

我想这归结为让自己使用控制器作为层次结构实体而不是对象/动作。似乎很容易以错误的方式使用控制器陷入这个陷阱。有人明白我在说什么吗？希望它不会太混乱。

编辑：如果我尝试在每个视图中坚持使用一个控制器；然后，我会将每个请求的代码保持在最低限度。这是最好的方法吗？

编辑：从每个人的说法来看，每个视图一个控制器似乎不符合我的最佳利益。我仍然有些担心，因为控制器似乎很快就会变胖，但这是另一个讨论。我还有一些关于何时决定使用控制器而不是动作的问题。一个很好的例子是堆栈溢出本身。在页面顶部，您有一个“问题”选项，我们可以假设它会将您带到“问题”控制器。我这样说是因为在右侧您可以选择“提问”，URL 指向“问题/提问”。这是有道理的，你使用问题控制器的 ask 方法。让我感到困惑的是，菜单上有“未回答”选项。看起来这本身就有一个控制器。为什么它不像“问题/未回答”那样只是问题控制器下的一个动作？这就是我变得混乱的地方。

4

11 回答 11

4

因为你的老板很喜欢流行语，所以告诉他查找“重构”

于 2009-01-06T21:42:21.137 回答
2

稍微偏离你的问题的主题......看在上帝的份上，不要忘记你的旧网址。原因是，当您打开新网站及其漂亮 URL 的开关时，搜索引擎持有的所有聚合内容都会慢慢过期，从而降低您的 SEO 统计数据。

更新：如果我尝试在每个视图中坚持使用一个控制器...然后我会将每个请求的代码保持在最低限度，但这是最好的方法吗？

如果我理解正确，每个控制器都会产生一页。这可能是一个非常糟糕的主意，我在维护职位上亲身经历过。如果您的内容与 OO 范例不太匹配，则将其归入一个类别：新闻稿、一次性、信息等，并将它们粘贴到仅提供这些视图的控制器中，或者更好的是每个控制器的数量类别留下更细粒度的控制。

我处理的“MVC”框架让一个控制器查看很快就变成了一个令人费解的混乱，有很多黑客和意大利面条代码。

我有大约 12 个用于创建“计划”的表单页面。

我不得不做一些类似的事情，而且看起来很愚蠢，拥有一个“planningform”控制器可能是最好的。是的，有多个表格可供输入，但您可以执行简单的操作，例如 $_SESSION['plannerController']['subject|action'][key][value] 来检查表单的每个部分。让每个方法处理多页表单的一部分也可能是一个好处（例如，如果你的老板说他们只需要 12 页中的 6 页，或者如果第 7 部分变得非常复杂并且需要自动完成 ajax 之类的东西怎么办）。

分组机制不一定使用它，因为它们之间有一些相关的东西。

我通常喜欢一个类，一个目的范式，但有时尝试这样做是没有意义的。在某些情况下，从教科书OO和其他时候学术BS可能会下地狱。你会发现不符合 OO 模式的东西，所以你可以退后一步，尝试将东西合并到常见的类别中。

于 2009-01-07T08:42:16.563 回答
2

每个控制器有一个视图有什么意义？

再次：

  1. 您没有加载超出每个请求所需的代码。你会加载你不需要的库、包、dll吗？当然不是。所以不要创建一个庞大的控制器文件，每个请求只会执行一小部分代码。此外，较小的文件更易于维护 imo，就像较小的方法和模块化代码一样。
  2. 控制器和视图之间有明确的 1:1 链接（特别是如果它们共享相同的名称）。这是一个约定。这是清晰和一致的。如果我正在查看视图模板，我确切地知道仅根据文件名加载它的控制器。不涉及任何思考。没有决定。没有妥协。

当一切都只是配对匹配时，有什么需要分离关注点？

关注点分离有什么需要？如果要对相关页面（控制器/视图）进行分组，请将它们集中在目录中。

我更倾向于编写一个控制器来控制以某种方式相关的多个视图。例如，前面提到的用户的添加/查看/编辑。您希望将类似的功能保持在一起，而不是在许多文件中搜索您想要的代码。在一个地方定义所有方法（针对特定对象）也很方便。使维护更容易。

我会恭敬地不同意。如果我有一个负责添加/查看/编辑用户的视图，那么通过 1:1 约定，我确切地知道负责的控制器。另一方面，使用您对类似功能进行分组的建议，如果我有一个经理控制器和一个用户控制器，哪个包含经理的添加/查看/编辑？用户还是管理员？现在你必须思考或搜索。

我使用 PHP 框架开发了一个项目，该框架为每个“操作”创建了一个单独的文件。命名为“对象（动作）”，它变成了一个需要维护的噩梦。

我不是在建议。

我已经使用 Django 一段时间了，它将所有模型保存在一个文件中，将所有视图（控制器）保存在一个文件中，并将模板（视图）分开保存。[Django 不是 MVC，但出于这些目的，让我们假装它是]。这使您可以将通用代码组合在一个地方，并且维护变得更加容易。

我现在感觉很恶心。我不了解 Django，我假设单个文件是可选的，但我无法维护一个包含数万行的文件。

我唯一的建议是——不要试图根据 MVC 的某些理想来组织你的项目。组织您的项目如何对您和您的领域有意义。

不不不。这是非常危险的建议。设计模式、编码约定和框架是为了一个目的而设计的——最佳实践和一致性。只有大师才能超越常规，并且只有在他/她独自工作的情况下。即使在框架的范围内，我也会不断地争取更高的一致性，以便在编写或维护代码时不必考虑。

于 2009-01-08T02:20:12.170 回答
1

每个控制器有一个视图有什么意义？当一切都只是配对匹配时，有什么需要分离关注点？

我更倾向于编写一个控制器来控制以某种方式相关的多个视图。例如，前面提到的用户的添加/查看/编辑。您希望将类似的功能保持在一起，而不是在许多文件中搜索您想要的代码。在一个地方定义所有方法（针对特定对象）也很方便。使维护更容易。

我使用 PHP 框架开发了一个项目，该框架为每个“操作”创建了一个单独的文件。命名为“对象（动作）”，它变成了一个需要维护的噩梦。

我已经使用 Django 一段时间了，它将所有模型保存在一个文件中，将所有视图（控制器）保存在一个文件中，并将模板（视图）分开保存。[Django 不是 MVC，但出于这些目的，让我们假装它是]。这使您可以将通用代码组合在一个地方，并且维护变得更加容易。

我唯一的建议是——不要试图根据 MVC 的某些理想来组织你的项目。组织您的项目如何对您和您的领域有意义。提出 MVC 是为了限制复杂性，而不是增加复杂性。

对于您的计划示例，我会将其制成控制器。www.example.com/plan/1 .. /plan/2 等等。这是有道理的，因为这些操作在逻辑上组合在一起以形成某些任务。

在我看来，控制器应该用于管理任务或对象。它的方法应该是完成该任务或修改/使用对象所需的特定操作。

于 2009-01-07T09:20:28.920 回答
1

去年我经历过类似的事情。我将我的大部分静态 PHP 网站页面转换为使用Kohana PHP 框架。我将每个网站部分都设置为控制器，其中包含各个页面的视图。主页视图包括页眉和页脚的其他视图。一些视图，例如文章视图，可以被不同的控制器重用。结果是一个与原始网站具有相同页面 URL 的 MVC 站点。

编辑： URL 的格式为 /controller/method?arguments。例如，在我的网站上，/computer/article.php?id=# 的 URL 使用了计算机控制器中的文章功能。反过来，计算机控制器使用文章模型将数据加载到具有嵌套段落视图的文章视图中。这也说明了即使该站点的先前版本在 URL 中具有带有 .php 扩展名的页面名称，这仍然可以转换为控制器类方法，并且相同的 URL 在基于 MVC 的站点版本中有效。这应该让您了解 Kohana 如何为您的网站工作。

于 2009-01-08T05:05:41.740 回答
1

我还有一些关于何时决定使用控制器而不是动作的问题。一个很好的例子就是这个 stackoverflow 网站。在页面顶部，您有一个“问题”选项，我们可以假设它会将您带到“问题”控制器。我这样说是因为在右侧您可以选择“提出问题”，URL 指向“问题/询问”。因此，您使用问题控制器的 ask 方法是有道理的。

好吧，我们不知道“问”是否是“问题”控制器的动作。该站点可能将“问题/询问”网址路由到不同的控制器，或者“询问”可能是“问题”目录中的控制器。此外，如果您打开“问题/询问”页面，您会注意到表单被发布到“问题/询问/发布”。现在“post”可能是“ask”操作方法的参数，但我猜它是“ask”控制器的“post”操作方法。

谁知道。但请考虑这一点：“问题”页面需要的代码是“提问”页面的数倍。加载“提问”页面时加载“问题”页面代码是否有意义。我认为stackoverflow的家伙会比这更聪明。

但让我感到困惑的是，菜单上有“未回答”选项。看起来这本身就有一个控制器。为什么不只是问题控制器下的一个动作？就像“问题/未回答”一样？这就是我变得混乱的地方。

我认为“提问”页面有自己的控制器的另一个原因。“问题”页面与“未回答”页面有更多共同之处。

于 2009-01-08T07:34:36.747 回答
1

在采取这样的行动时，您不仅改变了特定网站的实施，而且改变了人们感知它的方式。无论如何，您将不得不进行大量的重新编码，但您具有理解概念并具有如何做到这一点的经验的优势。

我的建议是坐下来，假装您对如何实施该站点一无所知，但要了解与您正在处理的站点类型相关的所有问题——它的要求和它的陷阱。创建一个基于 MVC 的关于如何做网站的概念化，然后尝试尽可能多地重用您拥有的代码。代码重用最终可能不可行，但从好的方面来说，至少您之前已经解决了许多相同的问题，因此实施起来应该不会花很长时间。

不要忘记，您始终可以使用路由来维护合理的 URL 结构，例如使用不同控制器的一系列表单页面，允许您使用不同的控制器、操作和视图，同时仍然可以从相同的布局或模板。

于 2009-01-06T20:09:51.543 回答
0

假设您手头有某种测试，涵盖了应用程序的大部分（全部？）功能。

  1. 充实您的 C 部分外观的真正基本结构。
  2. 忽略 M 和 V 实现此结构，或多或少只是将代码片段从面向页面的文件复制到控制器中
  3. 测试一切是否仍按预期工作
  4. 遍历每个控制器，提取一个“M”和一个“V”。“M”可能只是一个 Active Record（我知道，这不是一个真正的模型）或一个行表网关或一些可以很快实现的东西。控制器现在应该变得越来越薄
  5. 测试一切是否仍按预期工作
  6. 现在您已经了解了有关应用程序的所有信息，如果适用，请再次重构以提取域模型。在某些情况下，这可能只是浪费时间（仅限 CRUD/密集型应用程序）
  7. 测试一切是否仍按预期工作。
于 2009-05-12T20:57:44.563 回答
0

如果我理解正确，每个控制器都会产生一页。这可能是一个非常糟糕的主意，我在维护职位上亲身经历过。

我处理的“MVC”框架让一个控制器查看很快就变成了一个令人费解的混乱，有很多黑客和意大利面条代码。

这是因为框架、开发人员还是两者兼而有之？维护起来有多难？涉及哪些黑客行为，为什么？

在 php MVC 框架 Zend、CodeIgniter 和 Kohana 中，1 控制器到 1 视图非常适合我。在 ASP.NET 中，虽然不是 MVC，但 1 个 webform/view 映射到 1 个代码隐藏文件。

于 2009-01-08T03:57:02.100 回答
0

Nemetral的三篇博客文章让我更清楚地了解了整个概念，这些文章 解释了从传统网页脚本演变而来的模式，因此 PHP 逻辑与表示逻辑分离，因此就 MVC 而言，模型如何与视图分离。根据 Nemetral 的说法：

  1. 第一步是将迄今为止与 HTML 标记相结合的所有 PHP 代码移动到页面的头部。
  2. 第二步是将所有 HTML 标签移动到一个单独的文件中，并通过 PHP 包含访问它。因此，当发出请求时，它会被定向到 PHP 代码（控制器和模型），然后此代码请求 HTML 标记或演示文稿（视图）。

我在我的论文中写了更多关于这个的内容：http: //kreus-cms.com/kreus/pages/written_work

于 2009-05-12T20:35:44.583 回答
-1

我遇到的最大问题是决定何时实际创建控制器而不是仅将某些东西作为动作，因为它并不总是那么明确。

尽可能为每个视图使用一个控制器。那样：

  1. 您没有加载超出每个请求所需的代码
  2. 控制器和视图之间有明确的 1:1 链接（特别是如果它们共享相同的名称）。
于 2009-01-06T21:08:29.863 回答