Aaron Rouse said the following on 2/28/2007 3:32 PM: > I allow my beans to take in pretty much anything but then do checks in > my Sets within that bean to validate the data. If the data is valid > it sets it but if it is invalid it returns a error message that is put > into an array of messages. Basically I initiate the bean and then a > validating object, I use the validating object to run/set the setters > in the bean. If the validating object gets something returned to it > on any setter then it adds that message to its instance array for > errors. After all of these sets I check for a length on that array > and if something is found I halt the page and display those. I've found that validating in my bean leads to cases where it's tempting to use if/elseif's when you need an exception to the validation "rules". I have since moved to validation methods in my service layer. I have since leveraged this approach successfully since I can create common validate blocks that can be used by other validation routines -- sometimes your user needs to be validated differently. For example, people with admin rights get to break certain rules, while users editing their own account adhere to strict validation. So that leads me to validate() and validateByAdmin(). So I pass my bean to a method in my service layer instead of making the bean self-validating. Personally, self-validating beans are fine for when the system is simple, but as the application evolves (which they all do) things always get more complex. Just food for thought...but then again I'm usually building applications with very complex business requirements.
Best, .Peter -- Peter J. Farrell - Maestro Publishing http://blog.maestropublishing.com -- Co-Host of the ColdFusion Weekly Podcast http://www.coldfusionweekly.com 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]
