[Catalyst] ways to do stuff and why

Zbigniew Lukasiak zzbbyy at gmail.com
Tue Aug 22 09:26:35 CEST 2006


There is one practical argument for having the business logic in the model -
it is the necessity of using it from command line/cron job tools.  I have
not yet heard a similar argument from the other side - that is for having
the logic in the controller.

--
Zbyszek

On 8/21/06, leonard.a.jaffe at jpmchase.com <leonard.a.jaffe at jpmchase.com>
wrote:
>
>
> "Mark Blythe" <list at markblythe.com> 08/21/2006 :
>
> > > Matt Trout Wrote:
> > > I think the main bone of contention here is that Len is referring to
> his
> > > persistence layer as the model, whereas I consider it to just be a
> persistence
> > > layer - stuff like Model::DBIC::Schema is really only there for simple
> apps
> > > where what you're modeling *is* the database. If you're modeling a
> domain,
> > > then your Model::* stuff should be the model of the domain, and
> whether or not
> > > said model happens to use DBIC stuff as its persistence store should
> be merely
> > > an implementation detail that the Controller never sees.
> >
> > If the controller truly never sees DBIC stuff, does that mean that
> > your model logic never returns DBIC objects?  For instance, let's say
> > you have a logic method called findBestFit() that's supposed to return
> > shoes that fit a given person and activity the best.  Would it return
> > a DBIC ResultSet made up of Shoe row objects, or would findBestFit()
> > deal with those objects only internally and construct something
> > non-DBIC for the return?
>
>
> In my reality, I want findBestFit() to return a set of Shoes. The Shoe can
> be a
> DBIC  mydb::Shoe row object, from which I'm likely to call vanilla
> accessors,
> or they will be MyDomain::Shoe objects, each one decorating a mydb::Shoe
> object,
> and containing more shoe logic.
>
> findBestFit() should return objects that conform to your abstract notion
> of a shoe.
> Then you're insulated from your data source.
>
> Your business logic should deal with Shoes.  If using a DBIC Shoe row
> works for you,
> that's totally cool. But your business logic should contain one thin layer
> to insulate
> findBestFit() from the gory details of your data store.
>
> Again, I'll make the comparison to DBI/DBD which emulated ODBC in that you
> program
> to a general API, and the vendor specific stuff is under the hood.  So
> now, your ORM
> returns objects instead of hashrefs. But the specific method of setting up
> a query
> differs from ORM to ORM.  So you either choose to code to your ORM's API,
> or write
> a ORM independent access layer.
>
> In my MVC world, the Model is only the raw data, the Controller is the
> business logic,
> and the view is the display. The model simply gets the data from wherever
> it is stored,
> and puts it back when it's done.  The view shows the data in the model, to
> the
> logs, to the HTML page, etc.  The controller applies the business logic to
> the model.
> Sometimes the controller changes the view, other times it does its job
> silently.
> The controller wants to deal in abstractions: Shoes, Stockroom,
> ShoppingCart, Discount.
> It wants to execute Stockroom.findBestFit(myBigFeet.measurments()) and get
> back a set
> of Shoes to manipulate.
>
> In Catalyst, the model tends to map one-to-one to my idea of a model. It
> interacts with
> my data store.  The view maps well also. Here's my stash, work your magic.
> Now the trick
> with the catalyst controller, is not to put vast amounts of business logic
> in them.  Use
> them for handling web parameters, but then allocate business objects and
> manipulate them.
> It's better to instantiate a big wrapper object, ShoeStore and execute
> ShoeStore.gotAnyAirJordansInMySize(MyFeet), returning Shoes, which then
> get plugged into
> stash for the view to use, than to write the whole search in the catalyst
> action.  Better,
> because then you can call you business objects from any perl program
> regardless of the
> user interface.
>
>
> Len.
> My fingers hurt.
>
> ------------------------------
>
>
>
> 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 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/20060822/d2895a3e/attachment.htm 


More information about the Catalyst mailing list