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?
_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/show-participation
