[Catalyst] ways to do stuff and why

[Matt S Trout]

Kaare Rasmussen wrote:
>> There is one practical argument for having the business logic in the model
>> - it is the necessity of using it from command line/cron job tools.  I have
> 
> But it's easily overcome if you put your logic in separate modules. I don't 
> think that practical problems like this should dictate your design 
> philosophy.
> 
> More than that, it seems to me that it's a major shortcoming of the MVC model 
> that there's no real good place to put the real beef, the logic. i'd like to 
> keep the model as a persistence layer. The logic I'd put there should only be 
> concerned with keeping data consistent.
> The controller should only be interested in moving things around and the 
> viewer is completely out of the question :-)
> So in my view, business logic, rules, computations (other than simple data 
> twisting) and other stuff that has to be flexible doesn't really fit in. Of 
> course you can have it in the model, but then the model really has two 
> layers, a persistence and a processing layer.

Actually, arguably the Model should be the processing and logic layer - it's a 
*model* of your domain. That it talks to a persistence store of some sort (or 
to something completely different, e.g. a set of network servers in the case 
of an IM app) is merely an implementation detail.

-- 
      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +