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 -~----------~----~----~----~------~----~------~--~---
