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.