Re: OO Architecture

[email protected] (Tim Bunce) Wed, 28 Sep 2005 10:06:13 +0100
Newsgroups perl.dbi2.dev
Message-ID <[email protected]>
On Wed, Sep 28, 2005 at 02:45:38AM -0400, Jeff Urlwin wrote:
> > On Fri, Sep 23, 2005 at 09:58:01PM +0200, Jochen Wiedmann wrote:
> > > Hi, Tim,
> > > 
> > > >[Sorry for the delay in replying. I'm extra busy at the 
> > moment, not 
> > > >least because my wife is just a few weeks away from giving 
> > birth to 
> > > >our second child.]
> 
> Wonderful!  I hope everything goes well!

Thanks. So far so good.

> > > >But here's another, deeper, question that's more relevant 
> > at this point:
> > > >"is subclassing the DBI actually important?"
> > > 
> > > I do strongly believe: It is.
> > 
> > Ah, you can't get away that easily! *Why* do you strongly 
> > believe it is?
> > 
> > What examples of DBI subclassing can you show to prove your case?
> 
> Hmm...isn't Apache::DBI an example

Nope, as Ask says, it hooks in using connect_via (to be as transparent
as possible).

> There are a number of extensions out on CPAN that seem to have
> solved problems some people have, but I don't seem to worry about.  I'm
> not sure, honestly, how important each of those modules are in
> isolation, rather the capability of subclassing alows things we "normal"
> users don't think of (for better or for worse).

I'm thinking along the lines of "make it possible rather than easy,
and then encapsulate it so it's easy again" :)

Basically go with "DBI handle IS-A driver handle" (which makes
subclassing hard because each driver uses different class names).
But also supply a module that provides a transparent 'proxy' object
which HAS-A driver handle.  Then anyone wanting to subclass the DBI
would use that as the base class.

The win is that the price for re-dispatching the method calls is only
paid by those who want to use it.

Any problems with that?

> Regarding Java, I have not needed to subclass JDBC, per se.  I've used
> Oracle's ADF Business components for more of a row-oriented O/R mapping
> (loosely described for brevity here).  I've seen projects develop their
> own data access objects, which use JDBC more or less directly.  More
> focus seems to be on object-persistance than simple database access.  In
> my limited experience, large data-sets tend to kill these approaches, as
> most seem to approach the "many users, limited data" perspective of the
> web applications or OLTP applications where you can deal with a limited
> number of records/objects.  I have tended towards a more row-oriented
> approach, rather than how can I persist my objects -- so I may not be a
> good example of why you'd want to subclass.

"Me too". My request for examples on dbi-users is proving fruitful.

Tim.