How Do You Convert a Page-Based PHP Application to

Question

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.

Answer 1

The whole concept was made more clear to me by a series of three blog posts by Nemetral that explain the pattern as it evolves from a traditional Web page script and thus as the PHP logic becomes separate from the presentation logic, thus in terms of MVC, how a model becomes separate from the view . According to Nemetral:

1. The first step is to move all PHP code that was up to now coupled with HTML tags, to the head of the page.
2. The second step is to move all HTML tags to a separate file and access it via a PHP include. So when a request is made it is directed to the PHP code (controller and model) and this code then requests the HTML tags or presentation (view).

I write more about this in my dissertation: http://kreus-cms.com/kreus/pages/written_work

Answer 2

In making a move like this, you're not just changing the implementation of a particular site, but rather changing the way in which it's perceived. You're going to have to do a hefty bit of recoding anyway, but you have the advantage of understanding the concept and having experience in how to do it.

My suggestion would be to sit down and pretend you know nothing about how to implement the site, but everything about what issues are associated with the kind of site you're working on--its requirements and its gotchas. Create an MVC-based conceptualization of how to do the site, and then try to reuse as much code that you have as possible. Code reuse may not ultimately be feasible, but on the bright side, at least you've solved many of the same problems before, so it shouldn't take as long to implement.

Don't forget that you can always use routing to maintain a sensible URL structure for something like a series of form pages using different controllers, allowing you to use different controllers, actions, and views while still being able to borrow from the same layout or template.

Answer 3

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

Answer 4

If I understand you correctly, each controller would produce one page. This can be a really bad idea that I've experienced first hand in a maintenance position.

The "MVC" framework I dealt with that did the one controller to view quickly became a convoluted mess with lots of hacks and spaghetti code.

Was this because of the framework, the developer, or both? How was it difficult to maintain? What hacks were involved and why?

The 1 controller to 1 view works well for me in the php MVC frameworks Zend, CodeIgniter, and Kohana. In ASP.NET, although not MVC, 1 webform/view is mapped to 1 code behind file.

Answer 5

Assuming you have some sort of tests at hand, covering most (all?) of the functionality of your application.

1. Flesh out a really basic structure of how your C-part will look like.
2. Implement this structure ignoring the M and V, more or less just copying snippets of code from your page oriented files into your controllers
3. Test that everything is still working as expected
4. Go through every controller, extract an "M" and a "V". The "M" might be just an Active Record (I know, that's not a real model) or a row table gateway or something which is pretty fast to implement. The controller should now become thinner and thinner
5. Test that everything is still working as expected
6. Now that you know everything about your application, refactor again to extract a domain model if applicable. In some cases, this might just be a waste of time (CRUD-only/-intensive applications)
7. Test that everything is still working as expected.