How Do You Convert a Page-Based PHP Application to MVC?

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

Answer 1

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 2

Slightly off topic to your question... for the love of god don't forget your old URLS. The reason being is that the minute you flip the switch on the new site and its pretty URLS, all of the aggregated content held by the search engines will slowly expire, taking your SEO stats way down.

UPDATE: If I try and stick with one controller per view...I will then be keeping code per request to a minimum, but is this the best way?

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. If you have content that doesn't really match well to the OO paradigms then put it into a category: press releases, one offs, informational, etc and stick those into a controller that serves just those views or better yet a number of controllers per category to leave more fine grained control.

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.

I have about 12 form pages that are used to create a "plan".

I've had to do something similar and as goofy as it seems, having a "planningform" controller is probably best. Yes there are multiple tables to feed, but you can do simple stuff like $_SESSION['plannerController']['subject|action'][key][value] to keep each part of the form overall in check. Having each method handle part of the multi-page form can also be a benefit ( ex. What if your boss says they only need 6 out of the 12 pages or what if part 7 becomes really complicated and needs stuff like autocompletion ajax ).

grouping mechanism not necessarily using it because they have something related with each other.

I generally like the one class, one purpose paradigm but sometimes it just doesn't make sense to try and do that. There are cases where its clear cut, right out of the text book OO and other times the academic BS can go to hell. Your going to find stuff that doesn't fit the OO mold, so you can take a step back and try to merge things into common categories.

Answer 3

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 4

What is the point of having one view per controller? What need is there for a separation of concerns when everything is just pair matched?

I'd be more inclined to write a controller that controls several views that are related in some way. For instance, the aforementioned add/view/edit of a user. You'd want to keep similar functionality together rather than searching through many files for the code you want. It's also handy to have all the methods defined (for a particular object) in one place. Makes maintenance MUCH easier.

I worked on a project using a PHP framework that created a separate file per 'action'. Named like 'object(action)' and it became a NIGHTMARE to maintain.

I've been using Django for a little while now which keeps all the models in one file, all the views (controllers) in one file, and the templates (views) separately. [Django isn't MVC but for these purposes let's pretend it is]. This allows you to group together common code in one place and maintenance becomes much easier.

My only advice is - don't try to organise your project based on some ideal of MVC. Organise your project how it makes sense to you and your domain. MVC was proposed to limit complexity, not increase it.

For your plan example, I would make that into a controller. www.example.com/plan/1 .. /plan/2 etc. It makes sense because the actions are logically grouped together to form some task.

A controller, in my opinion, should be used for managing a task or an object. It's methods should be the specific actions required to complete that task or modify/use an object.

Answer 5

Where I am having the most problem is deciding when to actually create a controller vs making something just an action because it's not always so clear cut.

Wherever possible, use one controller per view. That way:

1. you are not loading more code than is necessary per request
2. there is a clear 1:1 link between controller and view (especially if they share the same name).