On Dec 3, 2007 1:36 PM, Peter Bell <[EMAIL PROTECTED]> wrote: > As for injecting beans into transients, it is a perfectly valid approach and > one you should play with.
One of the things I like about Transfer is that it provides a great hook for injecting stuff into transients: the "after new" event listener. This lets you have smart objects (as decorators that extend the generated Transfer-managed objects) that have full access to any services they need internally. > It really comes down to preference. I personally find User.save() an idiom I > prefer over UserService.save(User), although in practice if you need to > support remote method calls, you're probably going to need a > UserService.save() anyway. I'm starting to find that having save() on an object is much more convenient than requiring access to a service, especially given that Transfer's save() method can save any Transfer-managed object so where do you logically expose that on a service? Does each service have a save() method? What about a service that manages multiple objects - should it have saveFoo(), saveBar()? That's ugly. Much cleaner to inject Transfer into the Transfer-managed objects and let them save() themselves (it's actually an enhancement I'd like to see built into Transfer directly). However, I still prefer to have a service that fetches beans or creates new ones for me. I'm on the fence about delete() (since I rarely delete objects). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
