in reply to Performance v's Maintainability

There's another reason why you shouldn't put this stuff in more than once place: redundancy. You want to have the code that knows how to do each thing in only one place. This is the "once and only once" rule.

What you can do is make a function that returns a valid database handle and call that from each of your modules. You can have this function do its own caching of the database handle for now (just stuff it into a global) and then when you switch to mod_perl you'll be able to change it to use Apache::DBI.

Replies are listed 'Best First'.
Re: Re: Performance v's Maintainability
by Ryszard (Priest) on Sep 22, 2002 at 14:58 UTC
    Yeah, good call. What we've done (literally) is write a module that inherits all of CGI::Application's methods, (use base), then adds a few extra accessor methods its self. The .pm application you then would write in a standard C::A way uses our abstraction rather then C::A.

    So I guess in a way we have that abstraction layer Aristotle mentioned.. It does however feel messy to pass around objects, when, in purity I feel each module should survive stand-alone.

    I wonder if there is something i'm just not getting..