[Dbix-class] table-per-subclass - how it works?

[Patrick Meidl]

On Mon, Jun 18 2012, Alexander Hartmaier <alexander.hartmaier at t-systems.at> wrote:

> If I understand you correctly, you want to define a Perl object that
> doesn't directly relate to one table but to column from multiple tables?
> DBIC result objects always represent exactly one table with all its
> columns, primary and unique keys and relationships.
> What you want is a 'business' layer on top of that which you can define
> however you like, for example with Moose, that uses the DBIC objects so
> you don't have to deal with SQL.

exactly. in java lingo: the DBIC Result object is the equivalent of a
DAO (data access object), not a business model. of course, you can (with
both Hibernate and DBIc) use your DAO as your business model, but this
is not a very clean design.

that said, Hibernate *is* slightly more flexible regarding the mapping
of objects to tables. you can achieve similar results in DBIc with a
little bit of hand coding in the Result classes (as was pointed out by
other posters already), but it will get a bit quirky.

in my experience, it's better to do things the way your framework
intended them, rather than trying to bend the framework to work the way
another framework does, even if you think the other design is nicer.

HTH

    patrick

-- 
Patrick Meidl ........................ patrick at pantheon.at
Vienna, Austria ...................... http://gplus.to/pmeidl