Brian Kirkbride <[EMAIL PROTECTED]> @ 08/18/2006 01:57 PM:
> [EMAIL PROTECTED] wrote:
> > Matt S Trout <[EMAIL PROTECTED]> 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.
_______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
