Just thought I'd go back to the original post before the conversation goes off on a tangent and hijacks your post :-)
When you said: '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.' I think if you decide to make the beans aware of persisting themselves because its the only behaviour they will have is the wrong way to look at it. One thing that's a reality in many apps we write is a lot of the time it is simple CRUD stuff and there will not be much behaviour in some of our beans. I don't think then putting persistence methods in them suddenly makes them rich objects, I think its more to make the developer sleep better at nights thinking their beans have a purpose beyond a glorified struct! Also, if the User simply delegates save() to the injected DAO anyway its hardly a rich object, its still dumb and only doing simple delegation. Removing the DAO and putting the SQL INTO the bean WILL make it a richer object and an Active Record object and Active Record is something that may or may not work well depending on your situation. I'm happy for my services to be fatter as long as they don't start having methods that really should belong in a bean. Doing some application-specific tasks in the services is ok as far as I'm concerned. Things that can be handled with AOP WILL make my services thinner in time but for the moment having my <cftransaction>, save(), sendNewAdminUserNotification() etc in the service seems ok ________________________________ From: Michael Sharman <[email protected]> To: CFCDev <[email protected]> Sent: Tuesday, December 23, 2008 4:57:27 AM Subject: [CFCDEV] DAO in Service and/or Business Object 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 -~----------~----~----~----~------~----~------~--~---
