Mark Blythe 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? > > That's a choice I struggled with up front, and I finally decided that > sticking with DBIC objects made better sense for me than inventing a > whole new layer simply to abstract them and provide similar but not > DBIC-specific interfaces.
I tend to return the DBIC objects but make sure the controller only ever interacts with *semantic* methods rather than the DBIC-specific find/search/etc. so I could swap it out for such an extra layer if I ever need to. -- Matt S Trout Offering custom development, consultancy and support Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + _______________________________________________ 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/