On 10/29/07, Michael Sharman <[EMAIL PROTECTED]> wrote: > > > Hi everyone, > > Just curious how you would handle the following scenario with a 'User' > business object: > > User.cfc > UserService.cfc > UserGateway.cfc > UserDAO.cfc > > The UserService is composed with UserGateway and UserDAO for data > access operations. > > Now, I want more 'behavioural' methods in my User.cfc as I don't want > it to simply be a 'bean'. Let's say I have a User.validate() method, > part of which looks up a database to see if the current users email > has already been added to the system. As the validate() method is in > the business object (and not the Service) would you compose the DAO > into the User object as well? I.e. how do I manage database access > from the business object?
Just a note that I've gone over to the side that advocates not bothering with seperate "DAO" and "Gateway" CFCs. So when I say DAO, I mean whatever CFC you are using to interact with the database regardless of whether it is single-row queries or aggregate queries. I usually don't keep the validation methods in the object itself, but in a separate validation object that is composed into the business object. So if part of the validation is to hit the database to check for something, you can pass a reference to the DAO or the UserService into the Validator to let it look things up. I imagine doing it this way would be a pass by reference (either by a > factory or ColdSpring etc) so the 'cost' is ok because you won't be > instantiating a new cfc. Just means my UserService AND my User both > have a composed UserDAO. Is this a commonly used pattern? ActiveRecord follows this pattern, where the Object knows how to save itself. There are pros and cons to this approach, but the biggest con to me is that things can get messy if you need to (for example) perform a save that has to do more than just deal with the user table. My next question is if the UserDAO has a read() method which returns > an instance of User, how does the UserDAO get composed into this new > User object? Via something like: I would say that read() should not create a User object. If you want to go that route, create an empty user object, pass it into the DAO, and let the DAO populate it. In any event, if you want the DAO composed into the new user, a factory is probably the best appraoch. But that said, if the new User object already has a UserDAO composed into it, you can skip this issue because you can call User.load(), and internally the User can call the DAO to get the information needed to populate itself. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
