Hi Brian, Thanks for the clarification. In my current usage, the instance data and database match, so I haven't run into any snags. But I do get where I'm coupling the two and how that might pose a problem down the road. Sooner or later, I'll get it right. I think I need to meditate each morning, reciting the mantra, "Separation of concerns good...cohesion good...tight coupling bad...encapsulate...encapsulate...". ;)
Paul On 10/3/07, Brian Kotek <[EMAIL PROTECTED]> wrote: > > There's nothing wrong with passing THIS. The State pattern is based on > doing that. Passing the instance struct is an option, but only if your > instance data exactly matches up with the database. I prefer to have the > actual methods available, so that any business logic living in the getters > and setters is used by the DAO. That's really the whole point. The minute to > start coupling something to the internal state of another object (which is > what happens when you pass the instance data directly), you're losing > flexibility. > > On 10/2/07, Paul Marcotte <[EMAIL PROTECTED]> wrote: > > > Hi Greg, > > > > I've experimented with composing DAOs inside Beans. I don't know if > > there is a specific problem with using dao.saveRecord(this), but if you > > think about what "this" is, you're going to be passing the Bean and the > > composed DAO into the composed DAO, which just seems weird to me. For my > > implementation, I use dao.save(getInstance()), where getInstance() > > returns the variables.instance struct. You can call getInsance() by > > another name like getMemento() or something similar. To me, passing a > > struct off to the DAO is like passing a poor man's value object (which, in > > my understanding, is an object wrapper around an instance struct with no > > get/set methods.) > > > > Granted, I'm not a design patterns guru, so I'll defer to Brian and Tom > > on this point... > > > > Paul > > > > On 10/2/07, Greg Stevens < [EMAIL PROTECTED]> wrote: > > > > > > > > > Definitely right, it could be overkill. Wasn't looking at this for a > > > specific application though, just some generic methods / conventions. > > > > > > btw, in the quick examples posted, running dao.saveRecord(this) *is* > > > passing the dao a bean, assuming that dao.saveRecord(...) is being > > > called from within the bean itself. > > > > > > > > > On Oct 2, 1:38 am, Alan Livie <[EMAIL PROTECTED] > wrote: > > > > Or pass a bean (or an ID for deleting maybe) to your DAO's methods. > > > > > > > > Not sure if a service layer AND managers would be overkill for your > > > > application. It depends on the size of it and how large you expect > > > it > > > > to grow. > > > > > > > > Suppose it's nice to have maximum flexibility though. > > > > > > > > On Oct 2, 4:11 am, Greg Stevens <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > Thanks for the posts Brian and Tom. Definitely cleared up a bit > > > for me > > > > > and also reinforced some of the ideas I have been having lately. > > > > > > > > > @Brian - I feel the same way as you about the extends and IS-A > > > > > relatonships. That is what got me thinking about injecting the DAO > > > > > > > > into the bean and running something like dao.saveRecord(this). > > > > > > > > > @Tom - Thanks for the link, I will have to read it more thoroughly > > > > > later. > > > > > > > > > Right now I am leaning towards Tom thinking of a Service layer > > > being > > > > > more in charge of the various managers. Am going to have to read > > > up > > > > > some more articles on it. Perhaps finally dig into some more > > > Martin > > > > > Fowler or something. > > > > > > > > > Again, thanks for the help guys! > > > > > > > > > - Greg > > > > > > > > > On Oct 1, 2:58 am, Tom Chiverton <[EMAIL PROTECTED] > > > > wrote: > > > > > > > > > > On Sunday 30 Sep 2007, [EMAIL PROTECTED] wrote: > > > > > > > > > > > Part-1#comments) and it made me remember that I am confused on > > > exactly > > > > > > > what Service CFCs are. I posted this question to the blog, > > > however > > > > > > > would really like to receive a lot of feedback and different > > > opinions > > > > > > > on this. > > > > > > > > > > http://rachaelandtom.info/building-coldfusion-services-2 > > > > > > > > > > > I have been getting more into CFCs and proper OO methodologies > > > lately, > > > > > > > 90% of it is all making sense and every day more and more > > > becomes > > > > > > > clear, > > > > > > > > > > Doing it day and day out sure helps :-) > > > > > > > > > > > In my mind a > > > > > > > Gateway CFC deals with the database when retrieving more then > > > 1 > > > > > > > record. > > > > > > > > > > That's how Reactor uses them, sure. > > > > > > > > > > > My question is - I find I need to have a CFC that co-ordinates > > > actions > > > > > > > between multiple beans, takes some sort of action, performs > > > business > > > > > > > logic on 2 different beans that may represent 1 class or > > > perhaps 2 > > > > > > > classes (eg/ maybe 2 staff benas or 1 staff bean and 1 company > > > bean). > > > > > > > I am wondering - would this be considered a Service CFC? A > > > Manager > > > > > > > CFC? Something else? > > > > > > > > > > Sounds like a Manager to me. > > > > > > A Service would deal with the mechanics of locating the thing to > > > do the work, > > > > > > getting it invoked and the results passed back to the caller. > > > > > > > > > > -- > > > > > > Tom Chiverton > > > > > > > > > > **************************************************** > > > > > > > > > > This email is sent for and on behalf of Halliwells LLP. > > > > > > > > > > Halliwells LLP is a limited liability partnership registered in > > > England and Wales under registered number OC307980 whose registered office > > > address is at St James's Court Brown Street Manchester M2 2JF. A list of > > > members is available for inspection at the registered office. Any > > > reference > > > to a partner in relation to Halliwells LLP means a member of Halliwells > > > LLP. Regulated by The Solicitors Regulation Authority. > > > > > > > > > > CONFIDENTIALITY > > > > > > > > > > This email is intended only for the use of the addressee named > > > above and may be confidential or legally privileged. If you are not the > > > addressee you must not read it and must not use any information contained > > > in > > > nor copy it nor inform any person other than Halliwells LLP or the > > > addressee > > > of its existence or contents. If you have received this email in error > > > please delete it and notify Halliwells LLP IT Department on 0870 365 8008. > > > > > > > > > > For more information about Halliwells LLP > > > visitwww.halliwells.com.- Hide quoted text - > > > > > > > > - Show quoted text - > > > > > > > > > > > > > > > -- > > Paul Marcotte > > Fancy Bread - in the heart or in the head? > > http://www.fancybread.com > > > > > > > > -- Paul Marcotte Fancy Bread - in the heart or in the head? http://www.fancybread.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
