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.