>"Scott R. Godin" writes:
I guess I'm curious whether it even makes any sense to continue in an OO vein for this .. I had visions of being able to just
package Subscriber::Database; our ($db, $user, $pass) = ("dbi:Path:here", "username", "password");
package main; my $db = Subscriber::Database->new($subscriber_object);
$db->save() or die "Cannot save userdata : $!";
undef $db;
but perhaps I'm pipe-dreaming?
I mean, with an interface like this, I could have
$db->retrieve_match( column => "thing to match") and step thru the matches or $db->retrieve_all() to get everybody
my $href = $db->retrieve_emailers(); # loop thru the results # make a new Subscriber::Mailer object # fire off our monthly mailings from an HTML::Template or Text::Template
That's a perfectly good interface, however the Subscriber::Database class would not inherit from DBI, it would simply use the DBI module in order to interface with a database.
Inheriting leads to problems such as the next version of DBI introducing methods named retrieve_match and retrieve_all.
it's starting to get a little clearer now, yes..
Making the Subscriber::Database class containing generic routines and then inheriting from it to create a Subscriber::Database::DBI class might make sense (that class would just use DBI, not inherit from it). The UML architects would love it. Others would argue that how do you know what it generic until you've implemented two or three of the subclasses - so refactor later...
I have further visions of using both DBD::mysql and DBD::AnyData in different instances (exporting the db to a .csv file, for example) ...
Encapsulating the database code in a module (or class) is a very good idea. Sprinkling SQL randomly throughout the code is a nightmare I hope you never have to maintain...
these seem to be conflicting statements unless you're referring to my desire to pack all the actual SQL into the module so it's NOT in the front-end code and would be 'transparent' to it.
-- Scott R. Godin Laughing Dragon Services www.webdragon.net
