Your DAO implements a persistance mechanism. There's no need to tell it how to use the mechanism it implements.
That's what I thought, but...
...If you just have insert and update methods, then the manager can read a BO, and then immediately call DAO.create on that BO to have it duplicated in the DB.
DAO should really be nothing more than parameterized SQL statements, unless the persistance mechanism requires more logic (XML files, for example).
Doesn't this mean that the Manager also knows that the DAO is storing stuff in a SQL database, or some other storage medium that differentiates between "save" and "save new"? To use your terms, it seems to me that if the Manager chooses between insert or update, and the DAO blindly follows instructions, then the manager is telling the DAO how to use the mechanism the DAO implements.
For example, the Manager commands to insert the same object twice in a row; if the DAO implements a mechanism that does not require unique IDs (say, appending to a file) then that's fine (the read may be messed up, but the insert is fine), but if it implements a database and the ID is the primary key, then that throws an error. Only the DAO should care how it stores the data.
Is the purpose of a DAO to encapsulate the db schema, or the data access mechanism?
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: 310 478 6648
f: 310 235 2067----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
