No tree barking going on at all. I've been using a method similar to this in development projects for over a year, with great results. All of my projects are growing, changing projects, and maintenance has been easy.
I have a GenericData cfc that does introspection to detirmine field types and names. I then extend the cfc for each table, using cfproperty to make table and field properties available to the introspection of the base cfc. This method works great. I usually start with the inherited CRUD methods, and then override them in the extended cfc when additional complexity is needed. I don't spend time anymore writing trivial SQL. I only spend the time when something custom is needed. While there are certainly bad ways to accomplish the things we are discussing, the principle is right. -Sam Curren --- [email protected] wrote: > 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 > [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). > > 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/[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). 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/[email protected]
