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