good chemistry is complicated,
and a little bit messy -LW
Re: Performance v's Maintainabilityby Phaysis (Pilgrim)
|on Sep 22, 2002 at 20:36 UTC
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 / (Ph) Phaysis