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:
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.
In reply to Re: Performance v's Maintainability
by disciple
in thread Performance v's Maintainability
by Ryszard
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |