Ok so I thought I'd sit down for a few (thoughts not beer) and figure out MVC once and for all...
If I get it...I have seriously fallen victim to buzzword marketing...I thought there was alot more to it than what I just discovered...
I was convinced it was more a framework, than a design pattern as it's appears to solve those kind of problems or at least is touted as such...
Despite understanding the difference between a design pattern and an implementation of a MVC pattern I was subconsciencously convinced there was voodoo magic going like in many frameworks...
For the love of me, I couldn't visualize how three objects, which promoted separation of application parts could remain independant of each other and yet interact to yield a final result...
Mainly, I failed to see how that would be implemented at the lowest level, as thats how I try and learn things...I always work from the bottom up...I don't like just understanding the concept and using what been told to me until I fully understand it...
So here goes my current understanding of MVC (which is practically what i've been doing since I started PHP to one degree or another)...
Model or domain logic are completely independant of the other parts and can be implemented as classes or functions, doesn't matter, as all that is needed is the data returned...this was obvious...
The model is stable because unless your database schema changes or whatever else domain might use, the API doesn't change either...
Once you have a concrete design, your golden
The view, is NOT a template engine, but simple a wrapper around a template engine or other rendering device - by wrapper I'm not suggesting inheritence.
The view may be implemented as follows:
Code: Select all
class CxViewUser{
function showUserList()
{
$domain = new CxModelUser();
$arr_users = $domain->listUsers();
$m_smarty->assign('arr_users', $arr_users);
$smarty->display('user_list.tpl');
}
}
As the above demonstartes, the view MUST have knowledge of the Model as it's what drives the
view's view.
This makes the View slightly less stable than Model as any changes to the model, likely require changing the view as well.
Controller, this is the least stable as it has knowledge of both the View and the Model, so any changes to either may effect the controller as well.
The controller determines actions sent to it by user interaction, this can be implemented in any number of ways, one such method would be:
Code: Select all
switch($page){
case 'new_user': // Controller uses MODEL
$model = new CxModelUser();
$model->createUser($_POST);
break;
case 'list_users': // Controller uses VIEW
$view = new CxViewUser();
$view->showUserList();
break;
}
Because the above implements a dispatch mechanism which calls appropriate Model/View objects directly, this would be better described as a front controller?
Where as a
controller *could be* an object like:
Code: Select all
class CxCtrlUser(){
function createUser()
{
$model = new CxModelUser();
$model->createUser($_POST);
}
}
// And the front controller would then use the controller directly, like:
switch($page){
case 'new_user': // Controller uses MODEL
$ctrl = new CxCtrlUser();
$ctrl->createUser();
break;
}
The advantage of using controller objects as well is, now you can keep the front controller as clean as possible and code separation voila!!!
ie: Keeping model/view out of the front controller and letting it do it's dispatch work cleanly and clearly...
The dispatch work of a front controller is likely what MVC frameworks take care of for you???
As the other parts are likely to application specific to fit into a generic framework...
Anyways, what am I missing? Or is that the gist of it?
If thats it...it's waaay to over hyped...every article I read or thread for that matter pumped it's complexity to a point which made me not interested in pursuing any further, as my current approach to code separation is pretty much that...and got the job done!!!
I didn't see any benefits to switching, although, I can see now that a properly designed framework could make things a little clearer and easy to manage.
Cheers
