[Catalyst] ways to do stuff and why

[Mark Blythe]

> 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.