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