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