Working with the Web, there's going to be some kind of a dispatch or system for getting requests to handlers and there is going to be the handlers. Then with a database there is logic to fetch from and store to the database. You've probably just stepped into a trap. In a useful object design, objects are named after the nouns the system was written to operate on, and after the verbs it performs on those objects. The program is a reflection of the problem it's meant to solve and enough of the problem's world. If you're writing an accounting system, you would, ideally, have objects for lineitems, accounts, etc, and if you're doing a visitor type thing, then for actions that can be done on other objects. But, chances are, that's not what you're doing. Your problem has shifted from accounting to that of dealing with the computer you're programming. Your objects are named after this problem space instead: request handlers; the database; and so on.
MVC won't save you from defaulting to dumping business logic into big classes because OO-ifying the business logic isn't as pressing as setting up the web side and database glue.
You could subclass your DBIx::Class resultset objects and trust your schema to model the actual problem. That could work nicely if your database is full of useful views and uses views to abstract away the changing, growing actual schema. Or you could make a dedicated effort at putting objects in front of record set objects for important things ("account", "customer", etc) and letting those serialize/deserialize themselves using DBIx::Class with a has-a sort of relationship to the recordset objects they correspond to. There are other things you could use instead of DBIx::Class if you only want persistence -- KiokuDB comes to mind.
I don't have any brilliant thoughts right now other than to say, don't do that.
-scott
