I think people are getting lost in the weeds here and not considering the 40,000 foot view. As long as the database access is encapsulated, the rest of this is really personal preference. I personally have gravitated to the approach of letting the bean save itself, but purely for technical reasons: my beans tend to have additional logic that I want to run when it is saved, such as running validation, or saving associated beans, etc. It is quite difficult to do this if you do service.save(bean) because the bean has no way of "knowing" that it is being saved. But if I do bean.save(), ah, now I know what's happening and can do whatever I want. Just my take on it of course, but I've found it works very nicely so far.
I also use Transfer, and I prefer that my services have as little knowledge of Transfer as possible, ideally no knowledge at all. This doesn't apply to the beans, since the beans are Transfer Decorators and are couple to Transfer from the start. All this is really a digression though. I think that as along as you maintain good encapsulation and separation of concerns, the questions of whether the bean references a service, or references a DAO, or the service saves the bean, are typically not very important. Obviously you want to limit coupling as much as you can, but in the end these things *have* to be coupled in *some* way or nothing would ever happen. Do whatever works, and be consistent. On Tue, Dec 23, 2008 at 10:50 AM, Matt Williams <[email protected]> wrote: > > I too have been looking at this scenario. It seems like it has only > been a few months that CF-ers have been talking about their beans > having a service injected and thus being richer. > > Although it isn't technically circular, it does feel so to have the > UserService instantiate a transient User bean, which in turn HAS A > UserService. I haven't gotten my head around this idea yet and am > curious if this is what some people are doing. I would rather have > some other service object that has the simple job of creating the User > bean that can then have the UserService in there. > > One way that comes to mind would be to have the controller instantiate > the User bean. I've previously shied away from this idea (and from > using some controller built-in capabilities to create a bean based on > my form data automatically) as it feels like I'm blurring the > controller - model separation. > > So I go back to the idea of a bean factory service of sorts that > specializes in instantiating the User bean (or any transient for that > matter) and composing any needed services (e.g., UserService) into > that bean, probably via Brian K.'s bean injector. But then whose job > is it to call the rich/business logic functions on that User bean? The > controller? Yet another service? Ahhhhhh! Of course the only real > answer will be, "It depends." > > ------------------------------- > Matt Williams > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
