> not sure if you would call it a bean, beans are fairly dumb objects? > Probably more like a business object. > Its smart enough to know what it is, and tell you all its fields/types/rules > if you ask it.
In that case, it seems more appropriate that that business object consumes the generic set of values... since the business object itself knows best what data it needs, it should look through that glob of data you passed to it and grab everything it needs (and throw an exception if it doesn't get everything it needs). You dump your form/url/whatever arguments into one of the business object's methods to set its instance data. Then you can init() your generic DAO with a datasource, and the call to the create() method just takes in that business object and does something like this: Method create( businessObject ) : - call businessObject.getConfig() to get "instructions" on how to save this object (what fields to save, maybe what table to save to? Not sure what you're existing getConfig() does) - follow the "instructions", which will likely include a list of properties to grab from the business object (which will likely expose a getProperty(propertyName) method) In that scenario, all business objects would implement an interface that includes getConfig(), getProperty(), and any other methods the generic DAO would rely on to save a business object. The logic to grab only those data items relevant to a particular business object and validate those data items (apply type checking rules and any other rules) lives with the business object itself. Seems to me the major difference between this approach and what most of the other people on this list (including myself) do is where the knowledge of object-to-DB mapping goes. In this case, the business object itself knows how it maps to the database. In most other cases, the DAO knows how to map a business object to the database (which is why you see DAO's specific to business objects). ---------------------------------------------------------- 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]
