[Catalyst] ways to do stuff and why

[leonard.a.jaffe at jpmchase.com]

"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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20060821/57f24c30/attachment-0001.htm