Re: Performance v's Maintainability

What I'm doing with my website engine is what others have mentioned: I'm segmenting core functionalities into their own modules, complete with their own accessor methods, as a layer of abstraction between my application and the appropriate CPAN modules (CGI::, DBI::, etc). My aim is to create a Site::Request object, which is an interface to the CGI:: module, pass the reference of that to the Site::Auth object (which manages session state and user permissions), which creates the Site::SQL object, which in turn creates the DBI:: object. The core kernel code then passes the references to the ::Request and ::Auth objects to my templating subsystem module, Site::Template, to produce the output.

Currently, glacial development speed notwithstanding, it appears to me to be a valid and pliable approach. I'm considering ways to incorporate other tertiary modules for usage into the templating subsystem, like page creation and modification tools, without having to use standalone scripts in something like a seperate document subdirectory.

I suppose each of my modules could be considered standalone in functionality and abstraction, but each relies on the successful creation and execution of the previous modules. It seems the most sensible thing to me. I'm trying to make this code as portable and flexible as possible; I'm currently on a non-mod_perl web host, sharing resources with other domain owners, but down the road things may change. Having to switch over from MySQL to PostGreSQL should be easier this way. With the way the modules themselves are written, there are very few non-constant globals (everything else is in object instances), so the switchover to a mod_perl environment should, in theory, be painless as well. One could hope, right?

-Shawn / (P^h) Phaysis
If idle hands are the tools of the devil, are idol tools the hands of god?

Comment on Re: Performance v's Maintainability

Replies are listed 'Best First'.
Re: Re: Performance v's Maintainability by Ryszard (Priest) on Sep 23, 2002 at 07:44 UTC
I suppose each of my modules could be considered standalone in functionality and abstraction, but each relies on the successful creation and execution of the previous modules. Which is kind a what I'm doing... Lets say I have two modules A and B. Both these modules are part of the lower layer described in my orig. post. Lets say Module A goes and fetches some user information from an RDMBS and module B goes and fetches some information from an RDBMS. Both modules are abstracted to their respective domains (classes), both fetch different bits of non related information. For maintainability its easier to have both modules A and B create their own db handle fetch the data and return it to the upper layer... for Performance it would be better for the upper layer to pass a pre-created db handle (object) down to the bottom layer - which makes modules A and B not stand alone (or self sufficient). This need not apply exclusively to DB handles (I chose this example because of the overhead in creating/destroying DB handles), but any "helper" module that may be used more than once by the lower layer. What I’m hearing thus far, is maintainability matters, of course it does, but so does performance.. hence the trade off.. ;-)	[reply]

Replies are listed 'Best First'.

Re: Re: Performance v's Maintainability
by Ryszard (Priest) on Sep 23, 2002 at 07:44 UTC

I suppose each of my modules could be considered standalone in functionality and abstraction, but each relies on the successful creation and execution of the previous modules.

Which is kind a what I'm doing...

Lets say I have two modules A and B. Both these modules are part of the lower layer described in my orig. post. Lets say Module A goes and fetches some user information from an RDMBS and module B goes and fetches some information from an RDBMS. Both modules are abstracted to their respective domains (classes), both fetch different bits of non related information.

For maintainability its easier to have both modules A and B create their own db handle fetch the data and return it to the upper layer... for Performance it would be better for the upper layer to pass a pre-created db handle (object) down to the bottom layer - which makes modules A and B not stand alone (or self sufficient). This need not apply exclusively to DB handles (I chose this example because of the overhead in creating/destroying DB handles), but any "helper" module that may be used more than once by the lower layer.

What I’m hearing thus far, is maintainability matters, of course it does, but so does performance.. hence the trade off.. ;-)

[reply]