[Catalyst] Re: MVCR pattern

[Alan Humphrey]

Let's get pragmatic again. Perrin is IMHO successfully arguing the
need for a clean separation between stuff-that-is-useful-in-crontabs,
stuff-that-draws-pictures-blasts-out-HTML-whatever and
stuff-that-holds-everything-together. While we are at it, we could
call those stuffs respectively M, V, C and call it a day. Maybe M can
be further cut out between MP (persistence) and MB (business), I don't
know... But I have been doing various kinds of GUI-oriented apps for 4
years now (web or not, Perl or not, SQL or not) and I have found the
above definition of MVC to be a useful, reliable and extremely robust one.

- --
Dominique QUATRAVAUX                           Ingénieur senior
01 44 42 00 08                                 IDEALX

I think this neatly describes the problem.  Namely, when people talk about
"rules" they conflate business process rules and data rules.  Data rules are
things like "the customer name can be no longer than 50 characters".
Process rules are things like "if the quantity falls below a predefined
threshold, send an alert to the procurement specialist".  (And this ignores
all the UI oriented rules like "only display the 'create user' link to users
logged in with admin privileges".)

Because many of the process rules are driven by data in the database the
natural place is to put them close to the database.  But then we start
thinking about the "Model" as a thin wrapper around the database and
suddenly putting process rules there doesn't make as much sense.

So I try to put biz logic (both data and process) in the Model and just
accept that the Model will be more than a thin wrapper around the database.
I think this is where Perrin was going with the idea of "action" modules.

The key word in the previous paragraph is "try".  As Dominique encourages,
the "pragmatic" solution sometimes means putting the biz logic (especially
the process logic) somewhere else, either in the controller or in the view.

- Alan