Hi Brian,
Thanks for your response.
>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.
In you Validation.cfc would you have generic methods like isNull(),
isEmail(), testLength() etc?
Would I then have in my UserService something like:
if(oUser.validate())
{
//all good, continue to write to DB
}
Where the User.cfc has a composed Validate.cfc which in turn has a
composed UserService? Just needing to get my head around that one; my
UserService calls (eventually) a method on Validate which has a
UserService composed!
>There are pros and cons to this approach, but the biggest con to me is that
>things can get messy if...
Excellent point, and point taken! I imagine that you would normally
hande a save() operation from the UserService then?
>I would say that read() should not create a User object.
Again a good point, I have seen a lot of people do this so I've been
thinking about it lately. As above I image the database component
(whether that is a DAO etc) should return a query because you never
know what you'll want to do with it. Then your UserService can create
a business object is that is what you need.
Thanks again Brain.
On Oct 30, 9:15 am, "Brian Kotek" <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
