[Catalyst] ways to do stuff and why

[Zbigniew Lukasiak]

I am glad to see that the 'business logic in the model' side seem now to
prevail in the Catalyst world.  It was not so in the past - as this thread
documents:
http://lists.rawmode.org/pipermail/catalyst/2005-August/thread.html#1148
There is also a wiki page on this subject
http://dev.catalyst.perl.org/wiki/NecessaryBackgroundKnowledge

--
Zbyszek

On 8/18/06, Brian Kirkbride <brian.kirkbride at deeperbydesign.com> wrote:
>
> leonard.a.jaffe at jpmchase.com wrote:
> > Brian Kirkbride <brian.kirkbride at deeperbydesign.com> @ 08/18/2006 01:57
> PM:
> >  > 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'm leaning toward this as well, you might have convinced me with the
> composition argument.  I had been thinking of it in terms of inheriting
> from the
> model.
>
> I've moved from a home-grown ORM to Class::DBI to DBIx::Class in this
> project's
> history.  The business logic methods in the model classes had to change
> each
> migration.  Not a big deal, because it usually changing ->find to
> ->retrieve or
> something that simple.
>
> But not having to ever change a controller, script or CRON job by way of a
> set
> of Logic:: proxy classes would be nice.  Generally these bits don't have
> to know
> much of anything about the model implementation so it hasn't been much to
> change.  But when iterating over result sets it's hard to avoid the model
> implementation specifics.
>
> Maybe I'll spend the weekend whipping up some proxy classes to sit between
> my
> model and the rest.  I that the business logic methods in the model would
> be
> moved into these classes as well.
>
> Thanks!
> - Brian
>
> _______________________________________________
> List: Catalyst at 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/
>



-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20060819/362ac8df/attachment-0001.htm