Hey again Brian (S) ;-) On Feb 1, 2008 11:28 AM, Brian Sadler <[EMAIL PROTECTED]> wrote:
> > Hi Brian (K), > > I think if you're going couple the DAO to anything then the bean is > the obvious choice, given that the DAO receives the bean as an > argument and you have to access the beans properties or getters & > setters within most of the DAOs CRUD methods. It seems natural to me > anyway! :-) Yeah I don't see the difference between the bean doing dao.save(this) and the Service doing dao.save(bean). The DAO still has access to everything in the bean. > > > Also if you look at the DAO entry in the j2ee pattern catalog (http:// > java.sun.com/blueprints/corej2eepatterns/Patterns/ > DataAccessObject.html) the bean creates the DAO (my token appeal to ha > higher authority)! > That blueprint isn't taking the Service into consideration. The Service Layer pattern probably post-dates that article. > > But to answer your point about coupling, there may be more than one > client of the bean which wants to save it, and if you don't have the > DAO injected into the bean, each client is dependent upon both the > bean and it's DAO. OTOH if you have the bean in the DAO, they're only > dependent upon the bean - hence reduced coupling. > Again, if something wants to save the bean, I would say it should go through the Service. So each client is not dependent on the bean and the DAO, but it is dependent on the bean and the Service. Again, in my mind, since it is very possible that I want more to happen than just saving the bean (the Service might also employ logging, or security, or interaction with other related objects that, at the system level, I want to do something with when the bean is saved). If you go through the bean, this ability would be lost, unless the bean actually holds a reference to the Service, and when you call bean.save(), internally it actually does service.saveUser(this). Which might be a more valid approach to me because then you still have the oversight layer that the Service provides but you can still call save on the bean directly. > As for transaction management, yes by putting it "on top of" the > service layer, you are forgoing transactions at the DAO level. To my > mind it seemed really risky when I first read it, but the more I've > thought about it, the more it seems to make sense. My (admittedly > limited) understanding of it is that you can map transactions to use > cases, and since all use cases involve a request to the service layer > then that's the optimal place for transaction management. > Again, this would be invalidated by any use case where saving the bean also means doing something with other services. If any of the services you're interacting with also have transactions in them for whatever reason, the nested transaction issue still comes up. I'm really pushing for nested transaction support in CF9 because any way you slice it, this is really becoming a major pain. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
