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! :-)
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)! 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. 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. I did think of a kind of nested transaction, or a "transaction namespace-like" mechanism for allowing transactions at the DAO level but it seemed a bit cumbersome and actually unnecessary in light of the Cheers Brian S. On Feb 1, 3:20 pm, "Brian Kotek" <[EMAIL PROTECTED]> wrote: > On Feb 1, 2008 5:21 AM, Brian Sadler <[EMAIL PROTECTED]> wrote: > > > > > @Brian K > > > Hi Brian, > > > I'm Alan's "pro bean.save()" colleague and thought it was better that > > I contribute here rather than keep chatting to Alan away from the > > forum. Thanks for the excellent input on this, from everyone who's > > contributed! > > Hi Alan. > > > > > My take on this was that the Service layer shouldn't be "by-passing" > > the domain by accessing the data access layer directly. We've been > > looking at refactoring candidates in the code base and when I saw DAOs > > injected into the service layer, I thought it smelled (more a faint > > aroma, than a stink). TMM keeping the DAOs in the beans reduces > > coupling. > > Why? Now instead of the Service being coupled to the DAO, the bean is > coupled to the DAO. There may be pros or cons to the ActiveRecord approach > but reducing coupling doesn't seem to be one of them. What coupling do you > see as being "reduced" in your approach? > > > > > > > The point about where to place transaction management definitely > > caused us to stop and think again. Alan pointed out that (from Martin > > Fowler's PoEAA) the best practice is to have transaction management > > sitting on top of the service layer "like a condom". So, if we place > > transaction management on top of service layer and every request goes > > through the service layer (and why wouldn't it?) then why would there > > be any transaction management in the beans (or DAOs), even if they > > were composite beans using myObject.save()?... > > > In the service layer you just have: > > > <cftransaction> > > <cfset compositeObject.save() /> > > </cftransaction> > > > And once more let DAO.save() be accessed from the bean rather than the > > Service layer... > > But what if the save deals with multiple composed beans, and some of those > database steps are in fact their own transactions? Are you saying you'd > totally forgo any transactions in the DAOs and, by convention, decide that > the only place transactions will ever go is the service layer? Becuase if > any of the DAOs that are doing the saving contain a transaction, all of this > will blow up if you also have a transaction in the Service. > > The debate really isn't very crucial becuase as we've already pointed out it > is primarily a personal preference more than anything. But I disagree with > Jamie's earlier statements about how persistence is an "intrinsic property > of an object", but I'll reply to his post separately. > > Thanks, > > Brian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
