in reply to Re: Subclassing DBI instead of wrapping
in thread Subclassing DBI instead of wrapping
What I mean by "adding a few methods" is really just laziness. And in all cases I've done this it was for very topic-specific environments. For example, one use I've made is at a bioinformatics center where we have a database of genomic information. While many projects will have their own databases, there are certain very common requests which might be made from the public databases. For instance, getting all the peptide sequences for a list of given ids. While it's a simple enough SQL statement to write, it is used so often I wanted to provide an easier way to accomplish this frequent task. Originally I had a module which had a dozen or so similar shortcuts that took a database handle as one of the arguments (this also insulated the database design allowing me to improve and extend the schema with vastly less code breakage). However I also noticed I was pasting the same connection method in most of my code (same database, server, username, etc) and so I added a method to connect to that module. I'd barely done coding that and changing some programs to use it before it occurred to me that calling a function in my module to connect to the database, then handing that connection right back to other functions in the module was a bit of a waste of time.
So, I sorted out how to use AUTOLOAD (this was going on 6 years ago) and instead just wrapped the DBI. This made a lot of things much simpler; any code using my module could use the database handle returned just as normal, but they also got a small collection of simple, stable short-cuts for doing some very common tasks. I've found the template so useful I have reused it in a number of other similar projects. Nothing fancy, and as I said, nothing whatsoever that interferes with how any of DBI's built-in methods work.
|
|---|