Nice to see a posting that isn't spam!!! RADEMAKERS Tanguy said: - On the one hand, you have a type of format checking that's essentially about type safety, and that operates on single fields. If you have an object that exposes an "email address" field, you expect that field (if it's populated) to hold a syntactically valid email address, not just any old string (i.e. an email address is a string, but a string is not an email address). This kind of checking belongs in an object.
Only if all of your validation is against single objects or manageably small collections of objects. What happens if you want to import a large number of users - perhaps using an uploaded csv file? Assuming you implement that using CF (which is still plausible for that size of data set), how do you validate 2000 email addresses? I've never tried to create a collection of 2000 objects, but I'm guessing it wouldn't perform all that well. That leaves you with duplicating the code in both the object and a service layer. That's the only thing I can't square with building validation into an object - how it handles use cases where you want to deal with larger collections of data that don't make sense to instantiate as a collection of objects. As with most things OO, I'm probably missing something obvious :-> Any thoughts? Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RADEMAKERS Tanguy Sent: Tuesday, June 13, 2006 1:32 PM To: [email protected] Subject: RE: [CFCDev] Model or View? >What i do, cuz i'm a little intellectually lazy, like Ray, is to place a validate >function in my bean. Others abstract the validation to a separate object, but i >prefer having it in one package. It's just a little easier for me to see what's >going on. I think there are two different kinds of validation: - On the one hand, you have a type of format checking that's essentially about type safety, and that operates on single fields. If you have an object that exposes an "email address" field, you expect that field (if it's populated) to hold a syntactically valid email address, not just any old string (i.e. an email address is a string, but a string is not an email address). This kind of checking belongs in an object. - On the other hand, you have what's commonly referred to as business rules, which can operate on one or more fields. The email address field might be mandatory, or it might be restricted to email addresses from a certain domain, or whatever. This kind of checking belongs outside the object - usually in its own object, which accepts an instance of the object to be checked as an input parameter. I think it's a good idea to separate the two this way because business rules tend to be both more changeable over time and can also be context sensitive, whereas type or format checkers tend to be pretty stable. Bob from marketing might change his mind every two weeks as to whether the email field should be mandatory or not, or come up with all kinds of context related exceptions like "normal users can only enter email addresses from the same domain as their email address but administrators can enter email addresses from any domain, or not enter an email address at all if they want", but what constitutes a syntactically valid email address is not likely to change that much. just my 0.02$ /t ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.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' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
