NYCPHP Meetup

[Michael B Allen]

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

IMO none do and cannot.

The MVC paradigm as described in the much ballyhooed Design Patterns
book p. 5 is that the View just watches the Model for changes
performed by the Controller. For a desktop application that runs
continuously this works very well and it's a great example of well
thought out program design. But in the context of an HTTP application
MVC is completely impossible because the "model" only exists for the
duration of the HTTP request handler. As soon as the request returns
the model is destroyed. It has to be reconstructed from the database
each time. The "model" cannot hold any state not in the database. And
the View is on the client so it cannot reasonably "watch" the model.

The term MVC was hijacked by web developers that wanted to adapt the
MVC concept to web development but obviously they didn't even know
what it was!

Anyway, my point is that you should just forget implementing MVC in a
web application "properly" because there is no such thing. You should
just find something that gives your code a good structure. As you said
you need a "router". You need some kind of "application context" that
you can access from anywhere within your code so that you can reach
down and get some config info or a DB handle or whatever. You need a
"request" object that provides routines to safely get and maybe
validate parameters and then set headers for the response (or you
might have a separate "response" object like Java Servlets do). You
might want some kind of template processing help but these things tend
to be a little overrated IMO because PHP is a perfectly good template
language in itself (you could just create classes that represent the
common elements of pages and then subclass those to define the output
of that specific page). Another thing I recommend is separating "work"
from "output". Meaning the request goes through all classes once to
perform "work" like querying the database or whatever (you might call
this doWork()) and then returns all the way back to the router which
(if there are no errors) then calls an "output" routine (say
doOutput()) that goes through all classes again who can then format
and emit the data (or handle) setup by the "work" step.

Anyway, that's how I would do it. MVC is web apps is a misnomer.

Mike

On Tue, Nov 5, 2013 at 1:04 PM, Gary A. Mort <garyamort at gmail.com> wrote:
> 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



-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/