Peter J. Farrell wrote, On 2/28/2007 4:48 PM:
So after a while, letting the bean know how to validate itself became
unreasonable for us. In the end, we don't mind that our beans are very
stupid and a bit anemic. Those are my two cents and I'm sure in the
future I'll have more to say.
I don't see this as an either-or issue. I've not used this strategy in
CF, but in Java, I might create a Validator class which would know how
to validate very common things, like length, isnumber, isdate, and
such. Then, the model would compose an object of type Validator. But,
the key is, it would set its own validation rules to be followed in the
Validator object. Anything not common enough to make it into the
Validator would be performed in the bean itself. So basically, you
might have a routine like
// in the constructor, we've set up the validator as a private member
_validator, and set its rules somehow.
public boolean isValid()
{
result = true;
// perform custom validation, building an errorMessage as required.
if (somethingDoesntValidate)
result=false;
return result && _validator.isValid(my_info);
}
I've found the approach does a good job of staying DRY and abstracting
don't-need-to-know validation logic.
-Sam
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
