I am building a cgi::application that queries pretty extensively (at least for me) from a MySQL database. I am having trouble with maintainability, as the SQL code is mixed into the perl code and, unfortunately, we are changing the database schema fairly often right now. I was wondering what hints folks have about managing the SQL parts away from the logic of the code. For my limited programming skills, writing subroutines within my CGI::App is easiest but probably not the most flexible.
Use a DAO. Data Access Object. Create a package or many of just you SQL that return objects, or, arrays, or hashes, or whatever in the form that you want to manipulate them. For just the reasons you mentioned above I would not put my SQL in with my application logic. They are two different things. Almost as different as you application and display logics should be.
I like Class::DBI but it does incurr some perfomance penalties. But if you can abstract out your SQL and think about the type of data you want to return, it shouldn't be that hard to write those classes yourself. Be sure to keep common database stuff in a base class.
This would solve the problem of a frequently changing schema (at least for most cases) since your application logic doesn't care how it's stored just what it gets back. Then you will just have to change you're DAO (Class::DBI classes, etc).
HTH -- Michael Peters Developer Plus Three, LP
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
