如何将基于页面的PHP应用程序转换为MVC？ [英] How Do You Convert a Page-Based PHP Application to MVC?

问题描述

我一直在努力一段时间现在与如何重新编码基于页面的PHP应用程序使用MVC框架。为了背景，我不得不将应用程序移动到MVC，因为我的老板在做我。无论如何，我坐下来，打印出目录结构。然后我开始试图计划如何将这些页面转换为控制器/操作对。有些事情看起来很直接。例如，我有两个专门用于添加/编辑/删除用户的页面。这很容易创建一个用户控制器，并添加/编辑/删除的方法或操作。我有问题是决定什么时候实际创建一个控制器，而不是做一些只是一个动作，因为它并不总是这么清晰的切割。例如，登录控制器与用户/登录，或寄存器控制器与用户/寄存器。对我来说，如果对象可以做某事，这是一个动作，这是完全有道理，但它不总是那么清楚切割。

另一个例子是，我有约12个用于创建计划的表单页面。在我的头，我想我需要创建一个计划控制器，每个旧的页面将成为一个动作。所以我有一个控制器与12动作（方法）。我的问题是，虽然所有这12个页面都是数据输入表单，最终弥补这个计划，这是他们有共同点。每个页面在数据库中使用不同的表，并且彼此没有什么共同之处。基本上通过创建一个计划控制器，我只是真正使用它作为一个分组机制;不一定使用它，因为他们有相互关联的东西。至少在上面的用户控制器示例中;每个操作都使用相同的用户表，因此将这些操作分组到一个控制器是有意义的。我应该让每一个这些数据输入表单有自己的控制器吗？

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

编辑：如果我试图坚持每个视图一个控制器;然后我将每个请求的代码保持最小。这是最好的方法吗？

编辑：从每个人的意见，似乎每个视图一个控制器不会在我最好利益。我仍然有一些关注，因为看起来控制器可能会匆忙变得胖，但这是另一个讨论。我还有一些问题，什么时候做出决定使用控制器，而不是一个动作。一个很好的例子是堆栈溢出本身。在页面顶部，您有一个问题选项，我们可以假设您进入问题控制器。我说这是因为在右手边你可以选择提问，其中URL指向问题/问。这是有道理的，你使用ask方法的问题控制器。让我困惑的是，你有菜单上的未回答选项。看起来这有一个控制器自己。为什么不是在问题控制器下的一个动作，如问题/未回答？

解决方案

因为你的老板是流行词快乐，告诉他要查找refactor / p>

I've been struggling for some time now with exactly how to recode a page-based PHP application using an MVC framework. Just for background, I am having to move the app into MVC because my boss is making me. Anyway, I've sat down, and printed out the directory structure. I've then started trying to plan how I can convert these pages into controller/action pairs. Some things seem very straight forward. For example, I had a couple pages devoted to add/edit/delete of a user. That's very easy to create a "user" controller, and add methods or actions for add/edit/delete. Where I am having problems is deciding when to actually create a controller versus making something just an action as it's not always so clear cut. For example, a login controller versus user/login, or a register controller versus user/register. To me, if the object can do something it makes perfect sense to be an action, but it's just not always so clear cut.

Another example would be, that I have about 12 form pages that are used to create a "plan". In my head I would think I needed to create a "plan" controller, and each one of the old for pages would then become an action. So I'd have one controller with 12 actions (methods). The problem for me is, that although all 12 of these pages are data entry forms that eventually make up this "plan" that's all they have in common. Each of the pages use different tables in the database, and have nothing else in common with each other. Basically by creating a "plan" controller I'm just really using that as a grouping mechanism; not necessarily using it because they have something related with each other. At least in the "user" controller example above; each one of those actions uses the same "user" table, so it makes sense to group those actions into one controller. Should I make each one of those data entry forms there own controller?

I guess it just boils down to letting myself use controllers as a hierarchy structure entity instead of objects/actions. It just seems it's really easy to fall into that trap using controllers the wrong way. Does anyone understand what I'm saying? Hopefully it's not too confusing.

EDIT: If I try and stick with one controller per view; I will then be keeping code per request to a minimum. Is this the best way?

EDIT: From what everyone is saying, it seems that the one controller per view would not be in my best interest. I still have some concerns because it seems that a controller could become fat in a hurry, but that's for another discussion. I also still have some issues of when to make that decision to use a controller instead of an action. A good example would be stackoverflow itself. At the top of the page, you have a "Questions" selection which we could assume takes you to the "questions" controller. I say this because on the right hand side you can choose to "Ask a question", which the URL points to "questions/ask". That makes sense that your using the ask method of the questions controller. What confuses me is then you have the "Unanswered" option on the menu. It looks like this has a controller to itself. Why wouldn't it just be an action under the questions controller as in "questions/unanswered"? That's where things become muddy for me.

解决方案

since your boss is buzzword-happy, tell him to look up "refactor"

这篇关于如何将基于页面的PHP应用程序转换为MVC？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！