Steve Sapovits [[EMAIL PROTECTED]] wrote: > > In the case of DBI, my subclass is pretty thin. Right now it just > takes common names we use for databases and maps them to connection > strings. The power of that is that we've changed the underlying > connection strings several times; e.g., the database we refer to as > "developer" has moved a few times and had its connection strings > changed in the process. Having these specifics all wrapped in my DBI > subclass means my outside DBI users always use the abstract names and > my wrapper takes care of changing the underlying values as needed. > It also means I can easily switch to test versions of databases, which > helped a lot when we upgraded to a new version of Oracle.
What we did, before we knew about Perl OO, was to create a database module subroutine that took care of the connection to the database - all the scripts did to create a DBI connection to the database was to call that subroutine without any parameters. Using this method, we could change the paramters of the connection in one place. This seems very similar to, and almost exactly the same as, your method of subclassing the DBI, except we chose to use modules with subroutines instead of subclassing the DBI using classes and methods. I'm not knocking the OO approach to subclassing the DBI - in fact I prefer that method - I just want to understand if/how it is better than the modules/subroutines method, since it seems as though you can accomplish the same goal of database abstraction both ways. > > I'm also looking at adding some common error handling and tracking > code at some point -- again specific to things we do and not something > you'd find on CPAN. Again, we did this through a database module and subroutines. -- Hardy Merrill Mission Critical Linux, Inc. http://www.missioncriticallinux.com
