DBIx::Class - Related Tables

[Shevek]

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 think there is a confusion between "separation of concern" with
"layers of isolation". The perl community in particular has this
religion that isolation is the only good way to generate separation of
concern.

Separation of concern is achieved with one well defined interface which
is satisfiable by many subsystems. Prefer a language which has
interfaces. Perhaps this is the problem.

Layers of isolation are achieved by writing layer upon layer just to
keep something from directly accessing another pointer, but where each
layer adds neither semantics nor simplicity.

Some of the best separation of concern I've seen, e.g. Mina's
socket-filter stack, use the same interface at each layer, so it can be
run with one layer or as many as you want. Thus it generates separation
of concern with variable isolation.

S.