[Catalyst] ways to do stuff and why

[Christopher H. Laco]

Brian Kirkbride wrote:
> 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

Right. I agree completely on this. It's a matter of perspective.

Take Handel for instance. In and of itself, it has its own logic and it
has it's own model (storage layer and dbic). Now, when I use Handel
under Catalyst, it is now a model unto it's own. That's the only way to
have good reusability.

Whenever I start a new Catalyst project, my first goal is that all of
the core bits should be able to function outside of the context of a web
app. If I'm creating a store site admin page (Mango anyone?) that can
manager users roles, I first write modules that can manager user roles,
then I use those modules as catalyst Models.

-=Chris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20060818/9c01f92e/attachment.pgp