如何将基于页面的 PHP 应用程序转换为 MVC?
一段时间以来，我一直在为究竟如何使用 MVC 框架重新编码基于页面的 PHP 应用程序而苦苦挣扎.仅作为背景，我不得不将应用程序移入 MVC，因为我的老板正在让我.不管怎样，我已经坐下来，打印出目录结构.然后我开始尝试计划如何将这些页面转换为控制器/操作对.有些事情看起来很简单.例如，我有几个页面专门用于添加/编辑/删除用户.创建用户"控制器并添加用于添加/编辑/删除的方法或操作非常容易.我遇到问题的地方是决定何时真正创建一个控制器，而不是仅仅做一个动作，因为它并不总是那么明确.例如，登录控制器与用户/登录，或注册控制器与用户/注册.对我来说，如果对象可以做某事，那么作为一个动作是完全合理的，但它并不总是那么明确.
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.
另一个例子是，我有大约 12 个用于创建计划"的表单页面.在我的脑海中，我认为我需要创建一个计划"控制器，然后每个旧的 for 页面都将成为一个动作.所以我有一个有 12 个动作(方法)的控制器.对我来说，问题是，尽管所有 12 个页面都是最终构成这个计划"的数据输入表单，但这就是它们的共同点.每个页面使用数据库中的不同表，彼此之间没有任何其他共同点.基本上通过创建计划"控制器，我只是将其用作分组机制；不一定要使用它，因为它们有相互关联的东西.至少在上面的用户"控制器示例中；这些操作中的每一个都使用相同的用户"表，因此将这些操作分组到一个控制器中是有意义的.我应该让这些数据输入表单中的每一个都有自己的控制者吗?
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?
编辑:根据每个人的说法，似乎每个视图一个控制器不符合我的最佳利益.我仍然有一些担忧，因为似乎控制器可能会很快变胖，但这是另一个讨论.我仍然有一些关于何时决定使用控制器而不是动作的问题.一个很好的例子是堆栈溢出本身.在页面顶部，您有一个问题"选项，我们可以假设它会将您带到问题"控制器.我这样说是因为在右手边你可以选择Ask a question"，它的 URL 指向questions/ask".这是有道理的，您使用问题控制器的 ask 方法.让我感到困惑的是，菜单上有未答复"选项.看起来这本身有一个控制器.为什么不像问题/未回答"那样只是问题控制器下的一个动作?这就是事情对我来说变得混乱的地方.
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"
相关文章