I normally employ a ObjectManager that would handle the create() on both the objectDAO and childDAO independently. (transaction locking at manager level)
When retrieving these kinds of records I'm using an ObjectFactory that leverages the DAOs required to produce the biz object from the db layer. i.e. one object may contain arrays of other objects etc. I think of the "manager" as one that "puts stuff away" and the factory rolls my objects off an assembly line. Call me crazy! ;) My DAOs have: Init() Create() Read() Update() Delete() (optional as many instances I maintain history...so it may just retire old records) I use the concept of a gateway for direct data retrieval. Essentially read only operations where performance may be a factor. One example would be for reporting...I'm not going to retrieve and build 5,000 objects when I can satisfy the requirement with a simple recordset... -Stace -----Original Message----- From: Dawson, Michael [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 3:22 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] table DAO But, theoretically, you shouldn't think in terms of tables, but think in terms of objects. An object may need to store data in multiple tables. You would then have a DAO for that object. In the DAO, you may have a method "create()" that inserts a new record in the main table, then inserts a default child record in a userType table. Or, is that the business logic that handles that? :-S M!ke -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Van Der Hulst Sent: Monday, November 15, 2004 2:18 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] table DAO getAllActive() getByOwner( ownerID ) getAllPrecedingDate( date ) oh yep avoid that stuff like the plague. haha my early DAO's were like that before I realised all I needed was the one base DAO and the very occasional need to create a specialised subclassed DAO. Mind you in saying that I still haven't really tackled multiple tables/joins yet tho. TiM -----Original Message----- From: Doug Keen [mailto:[EMAIL PROTECTED] Sent: Tuesday, 16 November 2004 9:13 a.m. To: [EMAIL PROTECTED] Subject: Re: [CFCDev] table DAO > Ok then - so that brings up -another- question. getAll by itself, IS rare. > Most of the time I'm doing getAll where Active=1, or getAll where > Owner=Me, or some such. So if we have a Gateway CFC to handle getting > a > bunch of crap, where do we put filters? That's business logic - and > it seems like it would make sense in the core CFC for the datatype. Often, in that situation, I'll actually create different methods for different filtering options. For example, I may have a CFC with these *public* methods: getAll() getAllActive() getByOwner( ownerID ) getAllPrecedingDate( date ) Those public methods would then simply relay the call to a *private* method that contains the SQL and could have an interface like Tim describes: getAll( condition, order ) That way, you get the best of both worlds... the caller doesn't know about the table structure, but your SQL code is isolated in a single private method. The public methods simply relay the appropriate information into the private method and return the results. ---------------------------------------------------------- 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 [EMAIL PROTECTED] ## ## ---------------------------------------------------------- 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 [EMAIL PROTECTED] ---------------------------------------------------------- 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 [EMAIL PROTECTED] <table width=800 cellpadding=4 cellspacing=10 border=0><tr bgcolor=BDBDBD><td valign=top width=400><font face=verdana size=2 color=FFFFFF><b>AVIS IMPORTANT</b></font></td><td valign=top width=400><font face=verdana size=2 color=FFFFFF><b>WARNING</b></font></td></tr><tr><td valign=top width=400><p align=justify><font face=verdana size=1 color=808080> Les informations contenues dans le present document et ses pieces jointes sont strictement confidentielles et reservees a l'usage de la (des) personne(s) a qui il est adresse. Si vous n'etes pas le destinataire, soyez avise que toute divulgation, distribution, copie, ou autre utilisation de ces informations est strictement prohibee. Si vous avez recu ce document par erreur, veuillez s'il vous plait communiquer immediatement avec l'expediteur et detruire ce document sans en faire de copie sous quelque forme.</td><td valign=top width=400><p align=justify><font face=verdana size=1 color=808080> The information contained in this document and attachments is confidential and intended only for the person(s) named above. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution, or any other use of the information is strictly prohibited. If you have received this document by mistake, please notify the sender immediately and destroy this document and attachments without making any copy of any kind.</td></tr></table> ---------------------------------------------------------- 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 [EMAIL PROTECTED]
