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 > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
