--
Zbyszek
On 8/21/06, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
"Mark Blythe" <[EMAIL PROTECTED]> 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@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/
_______________________________________________ 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/
