Hmpft ... this is *exactly* what we need ... an omnipotent being on this list. :) Hell, even a semi-omnipotent being would be welcome.
Barry, what's your shortlist for the differences you're covering using your environmental variable approach? Do you mind posting it and sharing how you're structuring this within the DAO's? Right or wrong, i think it's worth discussing. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barry Beattie Sent: Thursday, April 28, 2005 4:00 AM To: [email protected] Subject: [CFCDev] multiple DAO's for different databases (was "While we're on the subject of DAOs") Chris Dempsey wrote: <quote> That said, in my meager experience, you tend to know ahead of time if this is required. Implementing the abstract DAO factory pattern is cool, but if you will only ever be on MySQL, its a bit of a waste of time. However, if you know you'll need to support XML, MySQL, Oracle, and SQL in the future, your code will be much more maintainable in separate DAOs. You can create a EmployeeOracleDAO.update(employee), EmployeeMySQLDAO.update(employee), EmployeeXMLDAO.update(employee), which take the same employee object and save it in different ways. </quote> ======================= my problem with this is the EmployeeOracleDAO.update(employee) Vs EmployeeMySQLDAO.update(employee) Vs EmployeeMSSQLDAO.update(employee) etc and long term maintainance of these as seperate files. EG: We have the same code base but different customers will have different DB's. Before: Informix. Now: Informix OR SQLServer OR MySQL... we have lots of maintainance on existing code and our new DAO's won't be immune as bug fixes and enhancements will be added in the future. considering that 90% of our (mostly) ANSI -compliant SQL will work across all decient db's as is, and that we don't use T-SQL, PL/SQL extentions (hell, we can't even use sprocs thanks to Informix) we're just starting to add in-line conditions and environmental variables to cater for "select TOP 1..." Vs "select FIRST 1..." sort of things (the environmental variables for the client's DB are set up when the app first starts). I haven't yet come across a query that is so radically different that it needs to be spun out into it's own db-type DAO. While it's still early days on this project for supporting many db types, it just seems* more managable for future maintainance by NOT having multiple DAO files (XMLDAO excepted - it's totally different). any thoughts, opinions, etc? thanx barry.b (*I'm no omnipotent being - I'm throwing this out there to see if the ideas are "madness" or whether there's a legitimate "method" in there...feel free to flame - it's all learning...) ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
