in reply to Best practices with Class::DBI

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.

Replies are listed 'Best First'.
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]

In Section Seekers of Perl Wisdom