It's easy to do single-table stuff with DBIx::Class. And even more complex actions are well supported, but you risk duplicating your code if you don't watch out.
Especially if you use Catalyst, it's easy to write the same piece of code to fetch or update related tables in several controllers.
This will surely and quickly become a problem.
Some people will have this in the Model layer of Catalyst. It's OK if all your work is guaranteed to be Catalyst. But what if it's not? What if you want to access your database from e.g. a stand alone server or a cron job?
I use DBIC ResultSets to fill out the hole between simple DBIC classes and the actual code I think that RS suits the bill in a nice way.
This is one way to have more complex database code with DBIx::Class. I'm sure there are a lot of other ways to do it. And I'm sure some people will tell me why I'm wrong :-)
But it's easy to do. Just watch.
In Project::DB::Class:
__PACKAGE__->resultset_class('Project::RS::Class');
Write methods in Project::RS::Class, e.g.
sub create_full {
my ( $self, $args_ref ) = @_;
$self->check_defaults($args_ref);
$self->validate_data($args_ref);
# Get schema
my $schema = $self->result_source->schema;
$schema->txn_do(
sub {
# Do something
}
}
}
and then use it from your controller, script, whatever:
$schema->resultset('Class')->create_full($args_ref);
