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:

  1. HTML Templates (via Template Toolkit)
  2. Main Programs
  3. 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)
  4. 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.


Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

  • Comment on (Ovid) Re: Re: Refactor method calls or not?

Replies are listed 'Best First'.
Re: (Ovid) Re: Re: Refactor method calls or not?
by mpeppler (Vicar) on Jan 19, 2002 at 04:45 UTC
    That's a similar architecture to what we did at eCircles. We decided to create logical database "requests" that mapped to one or more stored procedure calls with explicit input and output variables.

    This means that the application code doesn't know anything about the database - it only knows about these database requests, which allowed us to decouple the applications from the database somewhat.

    As for transactions, with Sybase at least we managed to never have a transaction that spanned multiple database requests. I realize that this may not always be possible, but keeping transactions short helps tremendously on general throughput for the database.


Re: (Ovid) Re: Re: Refactor method calls or not?
by perrin (Chancellor) on Jan 19, 2002 at 01:26 UTC
    I've had the same thoughts about this. However, to make database commits you have to know the big picture, and your data access objects don't.

    One approach would be to make a set of "action" objects that are allowed to manage transactions and call the data objects, but have no web-specific code in them. This would be similar to what the Java folks call a "session facade". In Java this is done because EJB performance sucks rocks, but in this case it would simply be an organizational tool.