[Catalyst] ways to do stuff and why

[Brian Kirkbride]

leonard.a.jaffe at jpmchase.com wrote:
> Matt S Trout <dbix-class at trout.me.uk> on  08/18/2006 12:33 PM:
>  > Eeeeek, not at all. The model should encapsulate *all* business logic 
> and
>  > similar - it should be a model of the domain with which the app 
> interacts. The
>  > Controller should be as thin a layer as possible whose sole purpose 
> is to
>  > arbitrate between the model's view of reality and the user interface 
> (i.e. the
>  > view)
> 
> I disagree.
> 
> In an MVC sense:
> The model is the data.
> The controller is the business logic.  
> The controller receives commands from the user interface, and 
> manipulates the models.
> The models are then displayed via views

This is what I had thought initially, but I have come to see the benefit of 
doing it the way Matt describes.

I have Catalyst and non-Catalyst web applications, CRON jobs and command-line 
utility scripts for my project.  They all need access to the data in the model, 
and that is provided by the ORM.  That can be accomplished in either your way or 
the logic-in-the-model way.

But many of the command-line tools need to do the same thing as a controller in 
the Catalyst application.  Sometimes the CRON jobs do too.  Since the code in 
the Catalyst controller is dependent on the Catalyst request life cycle, it's 
not in itself reusable.  I don't want Catalyst controllers calling the external 
scripts either.

At this point, if I want code reuse I have two reasonable choices:

A) Create business logic modules, ie. MyApp::Logic::CreateTrial, etc
B) Write my own business logic methods in MyApp::Schema::Trial->create(...)

Either is valid and from what I gather Java developers like the Logic route.  I 
chose (B) because I already have the classes and the logic is *usually* just 
operating on that class's data model.

I'm very interested in hearing others' thoughts on this, because it really seems 
to be a point of contention in MVC/Web programming.

Best,
Brian