Heh. I don’t actually know if "fat model" is a term outside the Perl lists/sites I frequent. I don’t have links right now but if some turn up, I’ll /msg you and update. I do have some demo/discussion for consideration.

The idea is simple: business logic is consumed by everything that consumes the model (DB code) so it needs to be in the same place to avoid duplication. It’s an extension of the MVC debate which makes the Controllers *very* thin, doing as little as possible and containing no business logic outside of authorization style stuff, the View being quite dumb and not doing much either, and the Model being "fat."

In a web app, the Controllers and Views might end up doing things with data; simplistic example: summing. In the fat Model this would be in the schema code.

This example, being simplistic, will only involve information that is available to the DB/schema already. It could involve external info/models/services. This is where things can get really "fat" if needed. You’d want the external stuff abstracted well so that you could mock it or run safe dev versions easily.

Example - checkout_total for a cart full of items

Cart has items, items have a cart, and items have a cost.

Obviously the information to get a sum of the items in the cart is available and can be put together a couple different ways. But it’s a multi-step process that is going to be needed over and over, so rather than putting it into DBIC syntax (which can be hairy or alterantively verbose for this kind of thing), or raw SQL, or letting an iterator do sums in a view, or some combination of all of those depending on the context, we’ll put it in the model.

Since it’s an ORM, we already know what calling it should look like: $cart->checkout_total. There is no limit to how many of this kind of helper we can write and what it can do is only limited by judgement.

Let your mind race ahead to write out checkout_total. What does it look like? Here’s the idiomatic implementation with DBIC–

sub checkout_total {
   +shift->items->get_column("cost")->sum;
}
[download]

Already, I hope, you can see that once you get your chops down, DBIC makes some easy but verbose things even easier and brief. Spelled out–

# Inside My::Schema::Cart or an auxillary class only
# loaded into the space on demand.

sub checkout_total {
   # My::Schema::Cart object.
   my $self = shift;
   # items is a has_many relationship.
   my $items_rs = $self->items; # ->items_rs to avoid contex ambiguity
+.
   # Get a DBIx::Class::ResultSetColumn object for cost.
   my $cost_col = $items_rs->get_column("cost");
   # Perform SUM.
   my $sum = $cost_col->sum;
   return $sum;
}
[download]

After you get your legs, the first version becomes more legible than the second. And this is really a baby example. You can continue this sort of thing, riding the relationships, to achieve really powerful queries that remain readable as they become more complex. The business logic can become self-documenting and every piece of every query can be individually testable which will not be the case with SQL libraries or hand written DBI stuff.

And now the full, working, demo code–

That example is fun and actually useful but a little weak because it’s based on a Result. Resultset stuff is where it gets really cool. There is a really good walk-through of that here: dbix-masterclass.xul, though no one seems to support XUL at this time so you might just have to read the plain text source of the slides.

The caveat with DBIC is that it’s not easy. The learning curve is pretty steep. I think it amply repays the investment.