RE: OO Architecture

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

Wonderful!  I hope everything goes well!

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

Hmm...isn't Apache::DBI an example?  I've used it before, and it's quite
helpful.  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).

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.

Jeff