RE: [CFCDev] What does a DAO delete method return?

[Dave Merrill]

Dave Merrill wrote: On another level, my current thinking is that all DAOs inherit from a base DAO class, which contains generic parameterized versions of some common methods. Instead of writing a delete method from scratch, for instance, an area's DAO can use this inherited method, passing it the arguments from, pk_col_name, and pk_list. Similarly, a generic single-table save method can manage both inserts and updates, based on passed arguments. If things are unusual or more complex, the area's DAO can skip these generic tools and use its own ad hoc method. What do folks think about this?  Honestly, I don't think it's a great idea.  DAOs are used to separate your data persistance layers from your model.  It appears that while building the application, this method might save you some time - but maintainence would be a pain.  I have enought to remember what to pass in - yet alone column lists etc...  Plus, I'm using a factory pattern and abstract classes for my gateways and daos.  I like knowing I can call: variables.appConstants.getGatewayFactory().getEamaGateway() and I have my eamaGateway (I'm using Mach-II here...).  Plus, I'm passing in objects (beans or TOs)...ah, I think I would go nuts. -- Peter J. Farrell :: Maestro Publishing  I've been thinking about this for a while, and I don't understand this response.   - Why would maintenance be a pain?   - How could you write a specific purpose-built insert method that didn't include a column list?   - Would you rather remember this:   ================== <cfquery name="qry_insert" datasource="#getDSN()#"> SET NOCOUNT ON INSERT users  (last_name, first_name, email_adr) VALUES  (  <cfqueryparam cfsqltype="CF_SQL_VARCHAR" value="#arguments.last_name#">,  <cfqueryparam cfsqltype="CF_SQL_VARCHAR" value="#arguments.first_name#">,  <cfqueryparam cfsqltype="CF_SQL_VARCHAR" value="#arguments.email_adr#">  ) SELECT @@IDENTITY as new_id SET NOCOUNT OFF </cfquery> <cfreturn qry_insert.new_id> ==================   or this:   ================== new_id = DAO.create(  table="users",  last_name="#arguments.last_name#",  first_name="#arguments.first_name#",  email_adr="#arguments.email_adr#" ) ==================     It's *not* about saving typing for the developer. It's about:   - Having a replicable plan for similar methods, so you and other coders know what to do, and what to expect as the return value, without thinking about it. Like any framework, the idea is that once you've seen how the users area handles inserts, you understand how every non-exceptional area does it.   - Having a facade to the create method, so different generic database-oriented DAOs with the same interface could be instantiated for different back ends. The alternative is hand coding raw sql for every create method, and rewriting it for every different back end.   - Not diving into db implementation details every time you write an insert routine. (Not that these are real obscure or anything.)     As far as passing in a TO, I don't see how that changes things. An area's DAO would just pass values from the TO into the generic create method, rather than passing column-specific arguments it received. If the TO represents a single table, and the TO field names and sql column names were the same, the second version above could even be written:     new_id = DAO.create(table="employees", argumentcollection="#TO#")   If the TO is a complex object, w data from multiple tables, the area DAO would call DAO.create multiple times, passing each embedded sub-object, with a different table name for each one. This is just like a non-generic version would do multiple cfqueries.     Am I barking at the moon here?   Dave Merrill  ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org