Spike, thanks much for taking the time to explain the background to your approach! I'm gonna keep it in mind, and it helped me to see that persistance and / or validation (for instance a login) doesn't necessarily have to move via a business object that contains all the parameters for a given "thing."
very good! n. :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Spike Sent: Thursday, August 12, 2004 9:34 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] type validation / try catch blocks >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... The main reason for having the validation in a separate object is that you can have a validation object per form. In some apps there are several different forms where you can update an object. Sometimes you're updating all the properties, sometimes only some of them. If you create a validation object per form you can put thorough granular checking for every form field into the validator because you know every single form field that should be there. Whether you also use the validator as a transfer object to pass to say the data persistence mechanism will depend on the application. I have used both approaches in the past and don't see an overwhelmingly good argument for sticking to one or the other. If you pass the validator object, you can strictly type the arguments to the persistence mechanism and reduce the liklihood of an object being passed where a setter hasn't been called. If you create a generic business object after validating, you can try to make sure that no instance variables are created except inside the setter methods. That way if your data perisistence layer tries to call the getter for an instance variable that hasn't been set, you get an error rather than having bad data inserted into the database. In practice I tend to lean towards creating an object for each form and passing that through to the database layer. I will often have several different CFCs that represent the data in a single database table. Several that are linked to the forms, one that contains summary data and one that contains detailed data. The only ones with validation in them will be the ones that are linked to forms. Now if we could only have interfaces in CFCs it would become a whole lot easier to ensure that I actually followed my own coding practices by creating a FormValidator interface :) Spike ---------------------------------------------------------- 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]
