On Mon, Jun 18 2012, Alexander Hartmaier <[email protected]>
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 ........................ [email protected]
Vienna, Austria ...................... http://gplus.to/pmeidl
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
