Michael, Coupla points:
1. Whereas I do have a User.validate() method, it won't check uniqueness constraints, therefore does not need a DAO. My rule of thumb is that instance methods should only concern the instance's own data (which may include composed objects). Checking uniqueness is a global issue which I have handled in a couple of ways: a. Each User object would have the UserService object composed into it. User objects are always created by a factory that knows how to set up this composition. The User object then uses the service for global operations. Only the service knows about the DAO. This still kind of bends my rule of thumb, so I'm moving towards: b. The UserService object has a save(user) method, which instantiates a SaveCommand object and passes it the user and the DAO. The SaveCommand instance has it's own validate(), which calls user.validate() and also does any global uniqueness checking. So we actually have three opportunities to validate here: firstly, the service checks that it has enough information to create the command; secondly, the command checks the global environment to make sure it's action is kosher; and thirdly, the business object asserts that it is internally self-consistent. Note that this says nothing about whether we are using an ActiveRecord pattern or not - the command object could still end up calling user.save() at the end of this process. In all of this, whether an object validates itself or you have a validator object (or both - User.validate() may just call a composed validator) is a matter of style. The self-validating object reads more clearly, but there's a lot of power in the validator object approach. 2. WRT read() - I've always used an ORM (Transfer), which in effect acts like a universal DAO and factory combined. In this case, read() (actually called get() in Transfer) can give you an object of your business class with very little fuss. Under the hood, I believe it's doing something like what Brian describes. Jaime Metcher > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] Behalf > Of Michael Sharman > Sent: Tuesday, 30 October 2007 7:34 AM > To: CFCDev > Subject: [CFCDEV] Data access from a business object? > > > > 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? > > 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? > > 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: > > createObject("component", "com.User").init(userDAO=this);? > > Thanks in advance! > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
