If the target database supports it, I place as much of
the sql as possible in a stored proc layer. The stored proc layer
can/should contain procs for retrieving, inserting, modifying and
deleting business objects - let the stored proc layer handle all
the joining and other table maintenance. You as a front-end developer need not worry about it. Once that stored proc layer
is in place, you can then automatically create a thin perl wrapper
around the stored procs (query the db, find the procs and params - write code to create code).
You may need to manually tweak the module but if the proc layer
is competently designed and implemented, you shouldn't need to.
In the past, I've coded up the thin layer as a 'uses' module that
just basically passes everything off to a contained DBI object. You
could always subclass DBI, but I always have a more comfortable
level by constraining DBI than opening it up for full use.
-derby
| [reply] |
Yep. As derby proposes ... write the SQL as optimal as you can, wrap it up as stored procs and then generate the DAO. In the project I spend most of my time on we have some 700 stored procs that need to be accessed from ASP and VB code ... what could be easier than to whip up some Perl code that'll connect to the database, load the info about the stored procs and generate the whole data access layer.
Sure the layer will not be any dandy OO, but if you wanted that you could put another layer on top of this thing very easily. I never felt the need.
Jenda
Always code as if the guy who ends up maintaining your code
will be a violent psychopath who knows where you live.
-- Rick Osborne
Edit by castaway: Closed small tag in signature | [reply] |
