[Catalyst] ways to do stuff and why

[Matt S Trout]

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/ +