一段时间以来，我一直在努力解决如何使用 MVC 框架重新编码基于页面的 PHP 应用程序。仅作为背景，我必须将应用程序移至 MVC，因为我的老板正在让我这样做。不管怎样，我已经坐下来，打印出了目录结构。然后我开始尝试计划如何将这些页面转换为控制器/操作对。有些事情看起来非常简单。例如，我有几个页面专门用于添加/编辑/删除用户。创建“用户”控制器并添加用于添加/编辑/删除的方法或操作非常容易。我遇到的问题是决定何时实际创建一个控制器，而不是让某些东西只是一个动作，因为它并不总是那么明确。例如，登录控制器与用户/登录，或注册控制器与用户/注册。对我来说，如果对象可以做某事，那么作为一个动作就完全有意义，但它并不总是那么清晰。
另一个例子是，我有大约 12 个表单页面用于创建“计划”。在我的脑海中，我认为我需要创建一个“计划”控制器，然后每个旧的页面都将成为一个动作。所以我有一个控制器有 12 个动作（方法）。对我来说，问题是，尽管所有 12 个页面都是数据输入表单，最终构成了这个“计划”，但这就是它们的共同点。每个页面都使用数据库中的不同表，并且彼此之间没有其他共同点。基本上，通过创建一个“计划”控制器，我只是将其用作分组机制；不一定使用它，因为它们有一些相互关联的东西。至少在上面的“用户”控制器示例中；这些操作中的每一个都使用相同的“用户”表，因此将这些操作分组到一个控制器中是有意义的。我应该将这些数据输入表单中的每一个都设置为自己的控制器吗？
我想这只是归结为让自己使用控制器作为层次结构实体而不是对象/操作。看来以错误的方式使用控制器真的很容易陷入这个陷阱。有人明白我在说什么吗？希望它不会太混乱。
EDIT：如果我尝试坚持每个视图使用一个控制器；然后，我会将每个请求的代码保持在最低限度。这是最好的方法吗？
EDIT：从每个人的说法来看，似乎每个视图只有一个控制器并不符合我的最佳利益。我仍然有一些担忧，因为控制器似乎会很快变胖，但这是另一个讨论。我还存在一些关于何时决定使用控制器而不是操作的问题。一个很好的例子是堆栈overflow本身。在页面顶部，您有一个“问题”选择，我们可以假设您会进入“问题”控制器。我这样说是因为在右侧您可以选择“提出问题”，该 URL 指向“问题/询问”。这是有道理的，你使用问题控制器的询问方法。让我困惑的是菜单上有“未答复”选项。看起来这本身就有一个控制器。为什么它不只是问题控制器下的一个操作，如“问题/未回答”？这就是我的事情变得混乱的地方。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
