title: How Do You Convert a Page-Based PHP Application to MVC?
body: <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.</p>
  
  <p>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?</p>
  
  <p>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.</p>
  
  <p><strong>EDIT</strong>: 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?</p>
  
  <p><strong>EDIT</strong>: 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 stack<strong>overflow</strong> 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.</p>