I disagree that $schema->resultset(‘Person’) is a significant improvement on $c->model(‘DBIC::Person’).
Me too! I don’t think the former is a significant improvement over the latter. They are, after all, more or less the same. The one big problem is that the latter version uses a nonexisting
DBIC::Person namespace. There are no
DBIC classes anywhere in the app. I think the model version would be much better if it was just written as
Marcus also points out that the model layer lets you configure multiple models and access them in a unified way. That is indeed nice. Unfortunately, that has the problem of tying yourself to Catalyst’s config, which is problematic for reasons I already described. Similarly, the unified layer only exists inside Catalyst, which is really only accessible during a web request. So now we’re stuck with recreating all of this if we need to access our models outside of a web request.
The long-term Catalyst roadmap includes the much-talked-about application/context split. Once this is done, presumably you will be able to access the application, which I take to mean config and models, outside of the context (of a web request). Once that is in place, I think many of my objections will go away. Unfortunately, for now I have to write my own application/context splitting code.