MVCR pattern (was Re: [Catalyst] Bing!)

[Perrin Harkins]

On Thu, 2005-08-11 at 10:10 -0400, David Storrs wrote:
> All true, but orthogonal to what I'm talking about.  Let's say you  
> define your generic ShoppingCart.pm module. Some part of your MVC app  
> needs to know which functions to call in ShoppingCart.pm--what I've  
> been talking about is what part that should be, the M or the C.

The common wisdom for MVC web apps goes something like this:
There should be a data access object for your shopping cart database
tables.  No URLs should map to it.  It should not know how to carry out
larger tasks or wrangle other data access objects -- it's just for
managing the actual shopping cart data.  Then there should be a class
(call it the action class) that knows how to carry out tasks like "add
an item to the shopping cart" by calling methods on the data access
objects.  This class should not have anything web-specific in it.  Then
there should be a method in your controller that reads input from the
web and calls the action class, passing any parameters it needs.  This
is the method that the URL gets mapped to.

Many people will shortcut some part of this, but I think it's a pretty
standard way for MVC web apps to split things up.  Catalyst apps usually
collapse the action classes into the controller and don't tend to keep
the separation between actions and their web context, but that's true of
nearly all the MVC apps I've seen built in Perl.

- Perrin