[Catalyst] ways to do stuff and why

[leonard.a.jaffe at jpmchase.com]

Brian Kirkbride <brian.kirkbride at deeperbydesign.com> @ 08/18/2006 01:57 
PM:
> leonard.a.jaffe at jpmchase.com wrote:
> > Matt S Trout <dbix-class at trout.me.uk> on  08/18/2006 12:33 PM:
> > > [ Matt's Way ] 
> > [ Len's way %]
> 
> 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.

Don't code the logic in the catalyst controller. This of the catalyst 
controller as
the glue between the web server and Business Logic.  let cat handle web 
issues:
parsing params & RESTful URIs, calling fillform(), then pass control into 
your
business logic, which validates it's input, manipulates domain objects 
(which are
composed by ORM objects from the Catalyst Model), and returns some data to 
its caller,
which in Cat's case, calls on one or more Views to produce output. 
 
> 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.

[Insert snarky Java comment here]

B couples my business logic too tightly with the ORM. ORMs fall out of 
fancy.
The whole point of MVC is loose coupling. Method A does not have that 
tight coupling. 
This is a bit of good advice I've picked up along the way: 
     Loose coupling of objects.  Code to the abstract class (API) not the 
implementation.

Sometimes it helps to forget about ORM's for a minute.  The hash or array 
of data returned
by DBI is still your Model.  It you want objects, you have to roll your 
own, around the DBI data.
Roll your own around the DBIC data, use object composition, rather than 
inheritance.  The coupling
is looser, and that makes your code less brittle.

I think some of this debate stems from folks wanting to have an initial 
for each object layer, and 
no more object layers than initials.

This is similar to the Django team misnaming their Controllers in the 
strict MVC sense.  When asked if
Django is MVC they say "it's Model/View/'Template".  They call their MVC 
Controllers "Views", and won't
enter into these kinds of name games.  They get away with it largely 
because in Django, There's Only
One Way To Do It.

In the end, it's a matter of taste and politics.  If we ever meet, we can 
argue vociferously over highly
caffienated beverages. I'll buy the first round.

Len. 



-----------------------------------------
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20060818/ef41b83c/attachment.htm