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

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

Answer 2

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 3

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 this stackoverflow website. 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". So that makes sense that your using the ask method of the questions controller.

Well, we don't know if "ask" is an action of the "questions" controller. This site could be routing the "questions/ask" url to a different controller, or "ask" could be a controller in a "questions" directory. Also, if you bring up the "questions/ask" page, you'll notice the form gets posted to "questions/ask/post". Now "post" could be a parameter for the "ask" action method, but I'd guess it is a "post" action method of an "ask" controller.

Who knows. But please consider this: The "Questions" page would require several times more code than the "Ask Question" page. Would it make sense to load the "Questions" page code when loading the "Ask Question" page. I'd think the stackoverflow guys would be smarter than that.

But 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.

Another reason why I think the "Ask Question" page has its own controller. The "Questions" page has much more in common with the "Unanswered" page.

Answer 4

I went through something like this last year. I converted my mostly static PHP web site pages to use the Kohana PHP Framework. I made each web site section a controller, with views for the individual pages. The main page views included other views for header, and footer. Some of the views, such as for articles, were reusable by different controllers. The result was an MVC site with the same page URLs as the original web site.

EDIT: The URLs are in the format of /controller/method?arguments. As an example, on my site, the URL for /computer/article.php?id=# uses the article function in the computer controller. The computer controller, in turn, uses an article model to load the data into an article view with nested paragraph views. This also illustrates that even though the prior version of the site had page names with the .php extension in the URL, this can still translate to a controller class method and the same URL works in the MVC based version of the site. This should give you and idea of how Kohana might work for your site.

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.

Answer 6

What is the point of having one view per controller?

Again:

1. You are not loading more code than is necessary per request. Would you load a library, package, dll, that you didn't require? Of course not. So don't create a massive controller file where only a small portion of the code will be executed per request. Also, smaller files are easier to maintain imo, just like smaller methods and modular code.
2. there is a clear 1:1 link between controller and view (especially if they share the same name). This is a convention. It's clear and consistent. If I am looking at a view template, I know exactly the controller that loads it based only on the file name. There is no thinking involved. No decisions. No compromises.

What need is there for a separation of concerns when everything is just pair matched?

What need is there for a separation of concerns? If you want to group related pages (controllers/views), lump them in directories.

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'm going to respectfully disagree. If I have a single view that is responsible for adding/viewing/editing a user, then with the 1:1 convention I know exactly the controller responsible. On the other hand, using your suggestion of grouping similar functionality, if I have a manager controller and a user controller, which one contains the add/view/edit for a manager? User or manager? Now you have to think, or search.

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'm not suggesting that.

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.

I'm feeling whoosy now. I don't know Django, and I'm assuming the single files are optional, but there is no way I'd maintain a file with tens of thousands of lines.

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.

No, no, no. That is very dangerous advice. Design patterns, coding conventions, and frameworks were designed for a purpose - best practices and consistency. Only a guru should step outside conventions and only if he/she works alone. Even within the confines of a framework, I constantly strive for greater consistency so that I don't have to think when writing or maintaining the code.