Home grown? Well, there's your problem right there.

This is a difficult problem space. Any naïve attempt at it is going to be bad. What moritz said about DBIC is important: it has notions of the abstractions that are actually involved and not just that of the table.row and the DBI connection. It also makes them lazy and highly extensible.

Your point #2 is an important design consideration and why many of us seem to have arrived on the notion of Fat models being the right design. This is quite easy to achieve in DBIC with different base classes, add ins, inflation, etc. Which makes unit testing really easy. E.g., theoretical and untested but close if not already correct–

use My::Schema;

my $schema = My::Schema->connection("dbi:SQLite::memory:");
$schema->deploy;
$schema->populate( my_baseline_fixtures() );

# Set 'em all up if you have logic not loaded by default.
$schema->load_namespaces( default_resultset_class => "+My::BizLogiks" 
+);

# Or customize per class if necessary.
for my $source ( $schema->sources )
{
    print $source, $/;
    $schema->resultset($source)->result_class("My::BizLogiks::" . $sou
+rce);
}

# Do some tests!!!
[download]

Update: fixed a typo; extended comment.