in reply to Re: Refactor method calls or not?
in thread Refactor method calls or not?
perrin wrote:
Regarding transactions, I think the transaction control belongs in the code that is calling these methods, not in the methods themselves.
There are some great ideas being tossed around here, but I want to address this issue specifically. In this system, I have what I think of as four layers:
- HTML Templates (via Template Toolkit)
- Main Programs
- Database API
- Generic database parent class for all subclasses
- Security subclass
- Modify subclass (this is anything that changes the database and it has its own db user)
- Select subclass (anything that only retrieves data)
- The actual database
The idea here was to have the main programs grab or update data and pass the results to the HTML template, but have none of the programs allowed to touch the database directly. Item 3, the database API, is the database "gatekeeper", if you will. We have so many old projects where database code was strewn throughout the system that I felt grouping everything like this would be much safer. Am I wrong in my thinking? By having the calling code (item 2 above) handle the commit, I then move database specific code out of the designated layer. This doesn't seem appropriate, but I'd be happy to hear counter-arguments.
Cheers,
Ovid
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.