[Catalyst] "Fat Model" Methodology?

J. Shirley jshirley at gmail.com
Thu Jan 21 18:45:55 GMT 2010

On Thu, Jan 21, 2010 at 9:37 AM, Jeff Albert <jralbert at uvic.ca> wrote:
> Hi List!
> I’m a new-ish Catalyst developer, converted from the ranks of the
> HTML::Mason faithful, and the recent nature of my dedication to MVC design,
> and to Catalyst’s fat-model pattern specifically, has left me with some
> questions that I hope you folks can help me with. I’m trying to understand
> how I would go about moving my application’s business logic, which seemed at
> first glance to fit quite logically into Catalyst’s Controllers, into the
> Model. Specifically, in this case I’ve got a Catalyst::Model::DBIC::Schema
> model to obtain my application’s data from; should I try to implement my
> business logic in that model (and if so, where? In the DBIC model PM? In the
> schema definitions?), or should I create a separate ‘application object’
> model which brokers requests from the Controllers and uses the DBIC model to
> implement them if they fit the application’s logic? I’ve looked far and wide
> to try to better understand how this pattern should work, since I can see
> the benefit of the better code reuse and easier maintenance it would entail;
> I just need some advice to get me started. Suggestions?

Much in line with the other replies (especially hdp's), I tend to
create composite modules that do the work if it spams multiple
objects.  If they only modify the DBIC class itself, or a direct
relation, I put the logic in the ResultSet/ResultSource package.  This
usually ends up with those methods being called by the higher-level
module, though.

For the non-DBIC-based packages, I then use either
Catalyst::Model::Adaptor or InstancePerContext, and in creating the
instance I pass in the connected schema.

This allows for some flexibility and doesn't impact things like unit
testing outside of Catalyst.


More information about the Catalyst mailing list