Thanks Brian, actually feels kind of nice to be wrong, at least when a better suggestion comes after it =)
I am completely with you on passing a reference to the object as opposed to passing just the instance data. Passing the instance bypasses all the great advantages of business logic rich beans. I currently just use these getInstance() / getMemento() functions when I need to dump the value of every property of an object. Nothing for production, just purely for debugging. Like the other day I was setting some properties of a CFC and saved it to a database, however the values I was setting and the values in the database where not matching up. Wanted to find out if it was the Bean, the DAO or perhaps some trigger in the database. I was able to quickly see that the data was being changed somewhere in the Bean by simply doing a <cfdump var="#bean.getMemento()#"/><cfabort/>. I did the dump/ abort right before making the DAO saveRecord() call so knew it was something within the Bean CFC. Was able to just keep moving the dump/ abort up a few lines in the code manipulating the Bean and saw exactly where the data was being changed. It actually turned out to be a real dumb logic error on my part which I won't get into here as it is a lengthy, rambling story. On Oct 4, 8:46 pm, "Brian Kotek" <[EMAIL PROTECTED]> wrote: > Yes Greg, you've got this one wrong. ;-) getInstance() is usually a static > method that you call on a class to return an instance of that class. This is > done when you make the constructor private (which, in Java, is almost always > a smart design decision because it allows you to encapsulate the creation of > the object and maintain control over what happens during instantiation). > > You can call it getMemento(), but I'm somewhat concerned about the > increasing popularity of doing this. Under what circumstances do you really > want to return the internal state of an object? I think in most cases it > would be better to pass the actual instance around, so that other code can > call methods on the object and you maintain encapsulation and reap the > benefits of any business logic that lives in the bean. > > On 10/4/07, Greg Stevens <[EMAIL PROTECTED]> wrote: > > > > > > > Hey Paul, > > > You bring up another problem I just recently encountered - whether to > > call a method which returns Variables.instance (a struct that holds > > all the instance data) getInstance() or getMemento(). > > I have been calling it getInstance(), however lately I have thought > > about using getInstance() in my Singletons in order to return them, as > > I think it is some sort of Java standard. I could be totally wrong on > > this though. I understand that getMemento() comes from the Memento > > pattern. > > > Any thoughts, getInstance() vs getMemento()? > > > - Greg > > > On Oct 2, 1:26 pm, "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.-Hidequotedtext - > > > > > > - Show quoted text - > > > > -- > > > Paul Marcotte > > > Fancy Bread - in the heart or in the head?http://www.fancybread.com- > > Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
