One additional note, that even if you go the route of having the DAO referenced from the bean, if you have an abstract superclass method that actually does the save within the bean (i.e. super.save()) and you later decide you want to use the service instead, your life is easier because the change of target is encapsulated in that method rather than all of your concrete beans.
On Tue, Dec 23, 2008 at 12:00 PM, Brian Kotek <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
