NYCPHP Meetup

[Gary A. Mort]

I do a lot of work with Joomla! so my experience tends to be with it - 
I'm curious on how closely other 'MVC' frameworks adhere to the MVC ideal.

Just to recap: MVC means separating code into 3 broad categories:
Models: Implement the actual program logic.  Retrieve records from the 
database, update records, etc.
View: Format the results of the program logic to display to the user.
Controller: Acts as the middleman and directs traffic.  Determines which 
models to load for the request, determines which view to use, etc.


For anything that is not a Model, View, or Controller generally the code 
gets stuffed into one or more "helpers" which over time can grow to be 
quite complex.


Nothing 21st century here.  Been doing this for decades, back in the 
80's we called it separating "business rules" from "presentation"...

Where things can break down a bit is that the MVC model can be applied 
recursively when building a large complex application.

So you have the main application which has a View for the whole page 
layout, a model for loading elements of the page, and a Controller 
directing traffic.  Then on that page, each block of discrete data can 
have it's own MVC process.   Blocks can have sub-blocks.. rinse and repeat.

Because of this, one element that is missing to a degree is the concept 
of "routing", where you determine from the request which primary 
application logic to use.   The main controller generally just knows 
"your doing something with the user, so I load the user controller and 
pass it on", while the user controller may check to see what you want to 
do - display a logon screen, authenticate a user, show the user profile, 
update user information, etc.


In Joomla! this ambiguity has led to a somewhat odd layout:

The "Controller" class is really functioning as the "Router".  It 
processes the request and determines what primary functionality is being 
used.   It generally does not do any security checks of any sort.  It 
loads a View and calls the views display method.

The "View" class functions more as the controller.   While the 
"Controller" class oftens will preload some default models for 
information - the view may have to load additional models for extra 
functionality.   The "View" class generally performs security checks and 
such.

The "Model" class is the only class to actually do what it says it does 
- it handles retrieving data, updating data, and performing actions.

"Views" have "templates" which basically function as "views" - ie they 
just display the data loaded to the various variables without retrieving 
new data or processing any actions.

This ambiguity can also lead to rather odd situations when dealing with 
3rd party code as programmers try to model the MVC pattern, so they put 
things which logically belong in the Controller class in the class 
actually named Controller...but since they have also inherited a lot of 
controller logic from the Joomla views they also use controller logic there.

It's also led to a rather odd schism between the framework and the CMS, 
where the framework has been refining the base "Controller" class so it 
functions more as a "Controller" should - but then their still left with 
this nebulous "View" class that is not really a View[the template is the 
view] so it ends up with a lot of legacy methods that are still in use, 
but has little logical sense.


I'm curious on what the state of other frameworks are regarding "MVC" - 
do they implement it "properly" or do they each have their own oddities?