Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

refactoring - is this layout a mess or should we leave well enough alone?

by archimago (Pilgrim)
on Oct 11, 2007 at 17:20 UTC ( #644284=perlquestion: print w/replies, xml ) Need Help??

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

management has decided that we will be refactoring the codebase of our mod_perl web app. i'm looking at our database access methods and trying to decide whether to re-structure them. here's the code i've inherited.
module layout:
relevant code from modules:
package; use DBI; sub new { db connection happens here } sub commit {...} package use base 'EG::DB::Clients'; use base 'EG::DB::Vendors'; use base 'EG::DB::Employees'; package EG::DB::Clients; use base 'EG::DB'; sub get_client_id_for_username { ... } package EG::Example; use EG::DB::Access; my $dbh = EG::DB::Access->new(); my $client_id = $dbh->get_client_id_for_username($client_username);
the good:
  • none of the db modules need to know about each other, they only know about EG::DB.
  • none of the client code needs to know about the specific modules, all methods are accessed through EG::DB.
  • if methods move, for some strange reason, from one module to another, no calling code needs to be updated
  • adding new db modules only necessitates a change to EG::DB::Access (an additional 'use base ...') and new 'use' statements don't need to be added to any other existing modules.
not so good:
  • for certain calls, search path seems longer than is necessary, so when client code calls a db method:
  • EG::Example->get_client_id_for_username()
    EG::DB::Access (no match) EG::DB::Clients (no match) EG::DB::Vendors (no match) EG::DB::Employee (match)
    and is even longer for the few methods in EG::DB such as when client code calls "new" or "commit" method:
    EG::DB::Access (no match) EG::DB::Clients (no match) EG::DB::Vendors (no match) EG::DB::Employee (no match) EG::DB (match)
so is it bad enough to warrant re-structuring? is the longish search path that expensive with mod_perl or should we just leave it alone. Does it really buy us that much convenience? Should be rolled into EG::DB to eliminate one additional search level? Thanks for any opinions.

Replies are listed 'Best First'.
Re: refactoring - is this layout a mess or should we leave well enough alone?
by ikegami (Patriarch) on Oct 11, 2007 at 17:27 UTC
    Method lookups are cached, so I'd say "no" if the only reason is to eliminate a search that doesn't even occur.
      ok thanks. do you find the layout convoluted or does it make sense to you?

        It don't find it very useful. It's not that it does anything bad, it's just that I don't see what value it adds. None of the "good" points hold any value for me.

        I'm not sure I agree with your second "good" point anyway. For example, when using get_client_id_for_username, the programmer knows he's using EG::DB::Clients. He *should* know he's using EG::DB::Clients. That's why the methods were placed in a seperate module in the first place. Perl doesn't care if the functions are in seperate modules or not. By hiding the partitioning of the functions, you're nullifying the advantage of creating the modules in the first place.

Re: refactoring - is this layout a mess or should we leave well enough alone?
by philcrow (Priest) on Oct 11, 2007 at 17:48 UTC
    I think your structure has already achieved sensible decoupling which is a prime goal of refactoring. Short of moving to an ORM, you have a plenty fine scheme.


    The Gantry Web Framework Book is now available.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://644284]
Approved by graff
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (2)
As of 2023-01-28 19:24 GMT
Find Nodes?
    Voting Booth?

    No recent polls found