Best practices with Class::DBI

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I've been fooling with using Class::DBI and CGI::Application.

I'm puzzled by what is the best way to deal with the framework of an application.

For example, say tables Music::Artist and Music::CD.
In CGI:Application I have a run mode say page1, that has to do processing on both tables.
The question is where does the code go. More percisly say a join, or a routine that gathers info from both tables.
It doesn't make sense to me that I should have things like Music::Artist->do_something buried in the Music::CD class. Do I stick all the real work in the base class Music::DBI? Then have all my run modes look like

sub page1 {
    my $self = shift;
    Music::DBI->do_all_the_real_work_that_page1_needs_done;
}
[download]

Comment on Best practices with Class::DBI Download Code

Replies are listed 'Best First'.
Re: Best practices with Class::DBI by saberworks (Curate) on Jan 20, 2006 at 21:39 UTC
There should be a clear definition of what the run mode methods do in CGI::Application classes vs. what your data handling class does. I usually use data handling classes just for handling data related to their namesake. Then the CGI::Application subclass only pulls input from $cgi, does whatever fiddling that has to happen in order to process the data, and then hands it off to an object that does the real work. The "real work" class takes arguments in a standard way, does all the real processing, and communicates the results back to the CGI::Application subclass. This is important because at some point you may want to interact with your application from something other than a web browser. Maybe you want to code a graphical front-end, or do some admin on the command line. You need to make sure the "real work" is properly abstracted and accessible from any type of script, not just a CGI::Application subclass. So you don't want to put any "real work" in the CGI::Application subclass because then you'd have to duplicate that if you ever want a command-line interface.	[reply]
Re^2: Best practices with Class::DBI by Anonymous Monk on Jan 20, 2006 at 22:16 UTC
I appreciate what you say about seperating the two. Its the real work class thats causing me troubles. If I understand you, my stupid code example using the do_all_the_real_work_that_page1_needs_done method is OK. The question then is when you say I usually use data handling classes just for handling data related to their namesake. What do you do if you need code that handles data from 2 data handling classes? I can use a has_a relation for simple things but when things get more complex, I'm at a loss as to how to lay it all out. I'm guess my problem is with basic OO design issues, I'm just looking for some clues as to how to lay it out.	[reply]
Re: Best practices with Class::DBI by stonecolddevin (Parson) on Jan 20, 2006 at 21:25 UTC
read the CDBI docs. you'll notice there's the option of associating tables/classes, using `has_a` (don't quote me on this...) meh.	[reply] [d/l]