Doug, Validation in the BO and validation in it's own object are both very viable, but they're for different purposes.
If you have BO validation, then you're validating the properties of a BO (duh), which means that if you update a single property, you still probably end up validating every property when you call validate. On the flip side, you can have 35 different forms on your site that update a given BO and have all your validation logic in a single place (the BO). If you have separate objects for validation, then you're usually (just often?) validating against a given form's submission. So in that case each form has it's own validation object, which means that you never do extra work when validating, but you potentially have to duplicate some checks. Personally, I prefer the former, but that's because I like my web client dumb as a post, with all the important goodies locked away in my backend. I used to do it the latter way, with per-form validation, and it worked well, but I think the encapsulation is easier to work with with the validation happening with the BO. My $0.02, barneyb On Thu, 12 Aug 2004 15:34:47 -0400, Doug Keen <[EMAIL PROTECTED]> wrote: > > "The business object shouldn't attempt to deal with an invalid > > parameter type, because it doesn't know anything about where that > > parameter came from, and that's essential for knowing how to respond > > to the exception." > > I sort of agree and disagree... the business object should definitely > know what kind of data it needs and whether or not it's valid. The > business object should *not* "respond to" those problems... it should > just identify the problem (by throwing an exception or flagging that > property as invalid). > > > "Just to through another idea out there, have generic setters that > > don't check type, or even a single set method that takes both a field > > and a value. Then have a validate method that rolls typechecking and > > semantic validation into a single method for the whole object. It > > should generate a collection of validation errors (missing password, > > birth date isn't a valid date, email is invalid, etc.) which can then > > be processed however. This is the approach that I've generally taken, > > and it seems to work quite well." > > > > Yes, that's what i've got at the moment, and i like how it's working. It's > > in the business object, as i've heard around that validation should be > > there, and it made sense to me. Now i'm wondering about Spike's approach of > > separating it out into a separate object... > > > > :) n. > > Sounds like that second approach I mentioned is what you're doing, and > I'm getting the feeling it's a good approach for most basic CF apps > you'll come across. Factoring validation out into a separate object > is kind of rubbing me the wrong way, though... it seems like you're > breaking up the nice cohesion of a business object. Before, the > business object was a nice encapsulation of business rules and data. > But after factoring, you're left with a dumb data bean and a > somewhat-stateless validation object that implements some of the > procedural aspects of the business object. I guess I don't understand > the advantage of splitting those apart. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
