php - 如何将基于页面的 PHP 应用程序转换为 MVC？

Question

一段时间以来，我一直在努力研究如何使用 MVC 框架重新编写基于页面的 PHP 应用程序。仅作为背景，我不得不将应用程序移动到 MVC 中，因为我的老板让我这样做。无论如何，我已经坐下来打印出目录结构。然后我开始尝试计划如何将这些页面转换为 Controller /操作对。有些事情看起来很简单。例如，我有几个页面专门用于添加/编辑/删除用户。创建“用户” Controller 并添加用于添加/编辑/删除的方法或操作非常容易。我遇到问题的地方是决定何时实际创建一个 Controller ，而不是只做一个 Action ，因为它并不总是那么明确。例如，登录 Controller 与用户/登录，或注册 Controller 与用户/注册。对我来说，如果对象可以做某事，那么作为一个 Action 就很有意义，但它并不总是那么明确。

另一个例子是，我有大约 12 个用于创建“计划”的表单页面。在我的脑海里，我认为我需要创建一个“计划” Controller ，然后每个旧的页面都会成为一个 Action 。所以我会有一个 Controller 有 12 个 Action (方法)。对我来说，问题是，尽管所有 12 页都是数据输入表单，但最终构成了这个“计划”，但这是它们的共同点。每个页面都使用数据库中的不同表，并且彼此之间没有其他共同点。基本上，通过创建一个“计划” Controller ，我实际上只是将其用作分组机制；不一定使用它，因为它们彼此有关联。至少在上面的“用户” Controller 示例中；这些操作中的每一个都使用相同的“用户”表，因此将这些操作分组到一个 Controller 中是有意义的。我应该让每一个数据输入表单都有自己的 Controller 吗？

我猜它只是归结为让我自己使用 Controller 作为层次结构实体而不是对象/ Action 。以错误的方式使用 Controller 似乎很容易落入这个陷阱。有人明白我在说什么吗？希望它不会太困惑。

编辑:如果我尝试坚持每个 View 使用一个 Controller ；然后我会将每个请求的代码保持在最低限度。这是最好的方法吗？

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

Answer 1

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