DBIx::Class - Related Tables

[Raphael Mankin]

On Tue, 2008-10-07 at 10:54 +0100, Dave Hodgkinson wrote:
> On 7 Oct 2008, at 10:10, Minty wrote:
> 
> > On Tue, Oct 7, 2008 at 9:03 AM, Dave Hodgkinson <davehodg at gmail.com>  
> > wrote:
> >> Then what's the benefit of an ORM? (general question, not just to  
> >> you :)
> >
> > Dunno about ORMs in general, but being able to pass a DBIx::Class
> > object into a TT template and have the template query the various
> > values and pull out the things they want seems like a big win.
> 
> 
> Which seems completely contra to Separation of Concern.
> 
> Punching through from template to data seems to be binding the layers
> together very tightly, making testing Hard.
> 

I have done this in the past with OJB/Struts (java not perl, but the
same problems arise). It does not make testing hard, in fact it becomes
easier provided that your DB actually implements FK constraints. From
the abstraction point of view, a FK is merely a pointer; following it is
not really 'logic'.

> >
> >
> > Especially the object chaining
> >
> > my $vars = { module => $db->resultset('Module')->single({  ...some
> > criteria ...}) };
> > $template->process('mytemplate.tt', $vars)
> >
> > [% module.author.email | html %]
> >
> > I'm not sure it's the best example - I'm thinking about where your
> > tables are connected in the schema, which lets you query tables that
> > can join the 'module' table simply by using . in the template.  Thus
> > the above 'module' table would only contain an 'author_id' column, and
> > the 'author' table would contain the 'email' column.
> >