I totally agree now and see your points. It just took me some working through it for it to personally make sense. Doesn't it always...
----- Original Message ----- From: "Barney Boisvert" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 08, 2003 1:40 PM Subject: RE: [CFCDev] Why not have DAO in BO? > This is how I initially set everything up, but the way Sean outlines is much > better. If your BO knows about the DAO, then your BO knows something about > persistance, and that's definitly a bad thing. > > Your DAO should simply create the instance data memento for a BO, and then > pass it to a BO. The BO should perform all operations on that data, both > changing it a recalling. Then, when the controller decides that it's time > to save the BO's state, it gets the memento and gives it to a DAO for > storage. The BO never needs to do anything with the DAO anyway, so it > doesn't make sense to have it as part of the BO. > > Cheers, > barneyb > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Gabriel Roffman > > Sent: Monday, December 08, 2003 9:25 AM > > To: Cfcdev > > Subject: [CFCDev] Why not have DAO in BO? > > > > I've read and reread Sean's Mach II article example and am trying to > > implement it now. However, my natural inclination is to have > > the DAO object > > be part of the business object? In the init method of the > > BO, I would call > > the read method of the DAO. So my init method of the BO would look > > something like this... > > > > <cffunction name="init"> > > <cfargument name="objID" type="numeric" default="0" > > required="false"> > > <cfset var instance = structNew()> > > <cfset instance.ID=0> > > <cfset instance.name="default name"> > > <cfif val(objID) GT 0> > > <cfset data = DAO.read(arguments.objID)> > > <cfset instance.ID = data.ID> > > <cfset instance.name = data.name> > > </cfif> > > <cfreturn this> > > </cffunction> > > > > What do you see as pitfalls of having the DAO be inside the > > business object > > like this? > > > > Gabe Roffman > > > > www.etesters.com > > > > > > ---------------------------------------------------------- > > 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] > > > > ---------------------------------------------------------- > 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] > > ---------------------------------------------------------- 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]
