"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.
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...
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...
--
Sam Holden
