On Apr 27, 2005, at 7:00 PM, Barry Beattie wrote:
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).
I've found that simple ANSI SELECTs and DELETEs across DBs are similar enough. In those cases, you may want to have concrete methods in the base class that provide that type of functionality. For the other two verbs, it gets more tricky.
For example, EmployeeDAO.read(employeeID) actually contains SQL. EmployeeMSSQLDAO does not override that method. EmployeeDAO.update(employee) is abstract, and relies on EmployeeDAOMSSQL to provide an actual method.
In my opinion, the trade-off with using ANSI SQL for everything is that it lowers you to the lowest and sometimes worst performing/functional/whatever common denominator. There are some instances where using stored procedures are the most effective technique - why hinder SQL Server's performance if Informix doesn't support it?
My application currently only supports MSSQL. But with the Mach-ii sample application architectures I patterned it on, hopefully adding other database types in the future will be simpler.
Chris
--
*************************************** Chris Dempsey Director, Information Services UCSB Graduate Division Quidquid latine dictum sit, altum videtur.
---------------------------------------------------------- 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]
