Personally, I like to consider two different approaches to this problem, which really boil down to the answer of this question: Are my business object allowed to exist with invalid data?
Let's say the answer is no (business objects *cannot* exist with invalid data). This means if you pass "New Year's Day" to setBirthDate(), which expects a date, an exception is thrown and the birth date is not set (preventing your object from entering an invalid state). It's then the responsibility of the caller to handle the exception. Advantage: You'll never have a business object in an invalid state, so when it comes time to persist the object with a DAO or perform some other higher level operation using that business object, you can safely assume that object is in a valid state and won't screw up your operation. Disadvantage: As soon as something goes wrong, it passes control back to the caller, making "multiple-problem" error messages difficult. Let's say the answer is yes (business objects *can* exist with invalid data). This means if you pass "New Year's Day" to setBirthDate(), which can accept any type of argument but wants a date, the function returns without throwing an exception, but the object now considers itself invalid and flags "BirthDate" as an invalid property. Advantage: It's easy to create that "multiple-problem" error message by simply asking the business object if it's invalid, and if so, what's wrong. Disadvantage: When you want to actually do something with the object (e.g., persist with a DAO), you'll always have to first ask the object if it's valid. You can never safely assume that the object is in a valid state. I'm currently using the first approach (no invalid business objects). I figure I can create those "multi-problem" error messages on the client side, and if those scripts fail, I always have that "one-field-at-a-time" validation on the server side as a back-up. The application is fairly complex (much more than just creating and persisting objects), so it would really be a pain to have to always ask my business objects whether they're valid or not any time I need to use them. I'm also looking ahead to Blackstone, when cfform will follow the xforms or xforms-like spec, which will make that sort of rich client side validation a trivial programming task. As always, the "best" approach depends on the nature of your application. -D On Thu, 12 Aug 2004 09:15:56 -0700, Barney Boisvert <[EMAIL PROTECTED]> wrote: > There's not reason you have to abort after the first error. IN your > procesing script, fill in the fields, catching any errors that arise, > and recording them to some temporary data structure. When you're > finished, then you can list all the errors and regenerate the form. > > 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. So the BO is handling the mistyped data (saying > "hell no, give me the right thing"), but it's not trying to convert > that error into something meaningful to the client (which is a UI > issue). > > 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. > > cheers, > barneyb > > On Thu, 12 Aug 2004 17:51:14 +0200, Nando <[EMAIL PROTECTED]> wrote: > > I know that could sound very right theroetically, but taking this case of an > > object that models a person as an example, you're filling in a form. You do > > your best but like all of us, you miss a few fields, 2 have wrongly typed > > data, etc. > > > > Submit. > > > > The process hits the first argument tag with a mismatched type and throws an > > error. I, the programmer, handle it outside the object and give you a > > "Please correct ..." message. You correct the first mismatched type and > > > > Submit. > > > > Bam. The process hits the second argument tag with a mismatched type and > > throws another error and renders another "Please correct ..." message. You > > think "Idiot! Who built this thing!" and somewhat angrily correct the second > > error. > > > > Submit. > > > > Unknowingly, you forgot 2 required fields, and although the process now > > clears all the argument tags in the business object, my validation routine > > catches the 2 empty variables and returns you to the form with yet another > > message. Now you're really pissed. > > > > Obviously, that's not the way it should work. > > > > Even if you're handling validation in a separate object for instance, > > talking the "It's not the business object's responsiblity to handle wrongly > > typed data", the above scenario would still play out in the same way, one > > error at a time. Hence, it still seems "irresponsible" to me, and users > > would immediately pick it up. > > > > And so it seems to me that the object asking for validation should be able > > to handle all validation comprehensively. Hmmm? Or am i talking myself into > > a corner here? > > > > n. :) > -- > Barney Boisvert > [EMAIL PROTECTED] > 360.319.6145 > http://www.barneyb.com > > > ---------------------------------------------------------- > 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] > ---------------------------------------------------------- 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]
