First, if you develop in Mach-II and your not on CFCDev, what are you thinking? Go subscribe. Now. Ok, with that out of the way we can continue...

The other day, Nando posted an excellent question to CFCDev inquiring about validation techniques. Specifically, he was asking if people implemented validation on setter methods of business objects. Barney responded and he described two schools of thought: 1) a business object is never invalid and therefore validation is done in the setters and 2) a business object can be invalid but can't be committed to the database until it passes validation. He also made the point that you should enforce business validation in your business objects but not input validation. However, he went on to make the statement that using unique keys on a database table to guarantee uniqueness was a "horrible option". Now, if you've looked at the Mach-II sample application you'll notice I use this exact technique to guarantee unique usernames. It didn't seem like such a bad idea to me (or Sean) so I asked Barney to provide clarification. He went into great detail about how he does validation in his applications. All very good stuff. However, I still couldn't fathom how his implementation was going to guarantee uniqueness. As we drilled down on it, he conceded that unique keys are the only robust method to guarantee uniqueness. Good. I'm glad we got that cleared up.

Anyway, the thread is a good read. It really makes you think about how you do things and why.