With the amazing buzz around RubyonRails, everyone seems to be hooked on the Model-View-Controller (or just MVC) paradigm – and do strive to mindlessly implement the ”Ruby way” into other programming languages without too much reflection and thoughts on how to do it. . Even tough most of the efforts I’ve seen so far seem pretty hopeless; I do believe you could actually do something good with MVC and PHP. Let me try to tell you how.
My ”systems thinking” is usually in the ”large professional genre” and it’s an absolute requirement that the PHP code developed is Efficient, Secure and Maintainable. To get a decent shoot at these, we really can’t reuse ideas and ideologies from Java or Ruby into PHP – we must adapt them to the strengths, weaknesses and ”php ways” to get a good result.
A model is simple include file. All functions interacting with a given model should reside within this file. There does not need to be a class wrapping the functions, and there absolutely doesn’t need to be a class-hierarchy with several layers and abstractions handled – java and ruby may be suited for this, but PHP(4 – I’m still undetermined on PHP5) really isn’t, so do you best to aviod it.
Simple include files, which acts with data (usually database CRUD-operations) should be placed in the model file, and making a new version of the site (another language or an alternate design) should re-use the model-files, and ideally just require changed views (changed controllers are okay, but could probably be avoided).
Views are just templates. There’s a bunch of PHP-template toolkits available. My preferred partner is currently Smarty, but I’m flexible. The Template Toolkit temptation to avoid seems to not getting too much power embedded into the templates/views – restrict your self to simple variable substitutions, if-statements and loops – not much more.
The primary misconception seems to be that there’s only one controller for every model. I’ve seen huge ugly files that handled dozens of parameters and acted upon these. I’ve seen huge ”if” and ”case” hierarchies, which was used to dig down to the controller instance which made the desired action, and it really doesn’t play well with PHP.
In my PHP MVC worldview, the controller is a collection of simple files, which (usually) interacts with the model, and (usually) call a view to display the data. I’m not too religious when it comes to the model-interaction – if the action is simple it may actually occur in the controller (it’s judgement call – which is better direct data interaction or a model-call and what’s most readable).
Putting it all together…
If you’re trying to adopt MVC then do try to make it work for you, not against you. If you’re making huge files, which needs loads of ”wrapping” (class-declarations, function calls and likewise) is probably not helping you much.
With a few easy rules, MVC might at a little more clarity to your PHP-projects:
- Include/model-files contain functions (or classes if it makes sense), which act with data.
- Views are templates (either separated from the controller with a templating engine or embedded within the controllers – hints: here documents).
- Controllers are small simple files, which helps you make nice and simple URLs and perform simple interactions with the users, the model and displays views.