> Also, Michael when you say 'UserService has a User' do you not mean > 'UserService has a method for creating Users'? ie UserService.getUser(id)
That's what I meant, sorry for the confusion :) On Dec 23, 9:48 pm, Alan Livie <[email protected]> wrote: > There's a good post by Marc Esher on a similar theme: > > http://blog.mxunit.org/2008/10/one-said-getter.html > > Also, Michael when you say 'UserService has a User' do you not mean > 'UserService has a method for creating Users'? ie UserService.getUser(id) > > Alan > > ________________________________ > From: Michael Sharman <[email protected]> > To: CFCDev <[email protected]> > Sent: Tuesday, December 23, 2008 5:58:06 AM > Subject: [CFCDEV] Re: DAO in Service and/or Business Object > > Thanks Mark, I considered that but I think I got held up on the > circular-ish dependancy. > > UserService has a User <--> User has a UserService (which in turn has > a UserDAO) > > I'm just not used to thinking that way. Once I've left the UserService > (calling User.save()) it feels funny to call an update() or create() > etc on the service again. I may as well just make the call from the > UserService instead of from the User. > > Good food for thought though. > > On Dec 23, 4:24 pm, "Mark Mandel" <[email protected]> wrote: > > > if you decide to go the User.save() approach (not my preference, but > > that's just me), I would inject the UserService into the User Object. > > > The Service is your Public API to the rest of your application, the > > DAO is not public to the application, only the Service should know > > about the DAO. > > > Mark > > > On Tue, Dec 23, 2008 at 3:57 PM, Michael Sharman <[email protected]> wrote: > > > > I hate to bring up a topic that has more than likely been beaten to > > > death but... > > > > My scenario comprises of the following: > > > > - User (transient or session managed business object) > > > - UserService (singleton handling business logic) > > > - UserDAO (handles database persitence relating to "users") > > > > Ok, let's say a form of user information has been submitted and has > > > passed validation etc, now it's time to save this data in the > > > database. For the sake of the argument we're currently in a method of > > > UserService as called from a view or a controller. > > > > I can do (at least) either: > > > - User.save(); > > > - UserDAO.save(User); > > > > The former feels right, it means I can have a lot more "behavioural" > > > methods in my User i.e. it knows how to persist itself etc. This would > > > likely require that UserDAO was composed into User which is fine, but > > > it also means that UserDAO would be composed into UserService as the > > > service will certainly want to talk to the database at some stage > > > (maybe to return an entire recordset of users etc). > > > > It's this which doesn't feel quite right...having the DAO in the > > > UserService AND the User. Then the lines might start to blur as to > > > where I put certain database calls, in the User or in the UserService. > > > > On the other hand performing UserDAO.save(User) is cleaner...only 1 > > > UserDAO which is composed in the UserService. But this means a lot > > > less behaviour in the User which doesn't feel right, leading to more > > > of a bean/VO approach. > > > > So my question is how people handle this seemingly common occurance. > > > All feedback welcome :) > > > -- > > E: [email protected] > > W:www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
