You can have your cake and eat it, too. If you abstract the persistence code into a class of its own, you can pass instances of this around without tying your framework to any specific persistence media. You just (a big just, though) have to define a consistent interface to your persistence class and can then hide access to a certain variety of SQL database, flatfiles, DBMs or whatever you may wish to use inside it, without giving up any maintainability. In fact, you're actually gaining another degree of maintainability. The extra layer costs some performance over the hard-wired approach of course, but it can be a relatively thin layer with only minor impact, and if your app is anywhere near as I/O-heavy as one might suspect by your description, it won't make any real difference.

"Every problem in computing can be solved by adding another layer of indirection."
(Another quote I'd love to know the originator and exact phrasing of.)

Makeshifts last the longest.

...solved by adding another layer of indirection
There is one problem not solvable this way: if you have too many layers of indirection... ;-)

I recall a discussion in PM about solving problem by adding layers of indirection about a year ago.

pmas
To make errors is human. But to make million errors per second, you need a computer.

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.

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..

I have never implemented this in Perl, and I am a Perl newbie, but have been programming in other languages for a few years. If someone else mentioned this then, sorry, I didn't understand it.

A common method of abstracting the database layer in other languages is to implement a class(module) that contains all database access code. This class acts as a mediator between your application code and the database. Do you need to get some user information from the database, call a method of the db class. How about updating the users information, call a method of the db class, etc... This provides the following benefits:

• The rest of your application does not care where the data is stored or how the module gets it. All it has to do is call the appropriate method.
• If you need to change your data access code, it is all encapsulated in one class.
• The class can be standalone.
• The DB handle is only created once, if you want.

One pitfall is the added complexity. I have found debugging this type of architecture is more complicated than its flatter counterpart; but I think the benefits normally outweigh the consequences.

I would be interested in knowing if anyone has implemented this in Perl and how it worked out for them. Even if you haven't implemented it, I would like to know if there are any reasons why this wouldn't be w good idea in Perl (I will be considering this architecture in the near future).

-disciple

I am not even sure if it is appropriate that I attempt to comment on your post. It would seem to me that you probably already know what I wrote.

That's what I posted, though you explained more verbosely and in-depth. :-)

Makeshifts last the longest.

There is something to be said for brevity. Unfortunately, I was too dense to understand it. :-)

I almost never ask "Which approach has better performance?" I've been developing a feel for that anyway. I almost always go for code simplicity and maintainability. As perrin says, make sure you stick with Once and Only Once.

If you're having measurable performance issues after that, profile. Otherwise, the best we can do guess. I tend to be wildly wrong when playing guess the bottleneck.

Do you do any forking? If not I say passing around a DBI handle is pretty dang reasonable. That way when you go to mod_perl, and use Apache::DBI (which you probably will), you get the performance benefit.

BTW: I like DBIx::DWIW ;)

update: When I say maintaining sessions, I don't mean maintaining some kind of database (like a playlist), I mean managing data that has a short lifespan, that's supposed to expire and go away.

____________________________________________________
** The Third rule of perl club is a statement of fact: pod is sexy.

Well there's some things you shouldn't do using the database, like maintaining sessions.

This doesnt quite ring true to me. I'm assuming you're talking about performance...? However I'm interested to know how you correlate user data back to a user without using the session_key as the identifier of the user...

I have a setup where a user may store personal data on website (for example a playlist). I use an RDMBS as the storage mechanism as it is robust, relatively fast and i can port my SQL92 complient application to another RDMBS relatively painlessley. For the user to edit that bit of data (for me to retrieve the correct data) I correlate the session_id to a user_id via sql...

OT to the original post, i'm interest in what mechanism you use, or would recommend..

There's nothing wrong with storing sessions in a database. If you have a cluster of servers, it's the simplest way to go.

I'm sure this strategy of doing session or other short-lived stuff out of the database works for smaller stuff (like mine) but there *is* a definate cost to iterate through a directory entry. Your database and operating system have all kinds of logic to cache things in memory that aren't going to be used if you do something simpler. It's something to keep in mind anyway.

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?

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.. ;-)