User Input Validation - ColdBox Series Part 9a

I'll be keeping an eye on this thread as well. Currently I'm in the "separate validation object" camp, but that's only because that's how I currently do validation. :)

Not to get ahead of the thread too much, but I don't see bean-based validation as a 100% solution because not everything on a web form necessarily maps to a bean property: sometimes a form value is required to determine a course of action rather than a piece of data, some value that must be valid but is not persisted in a bean or the database.

There are so many ways to do this Jason, like you have found out. I have used almost all of them and I have found a preference to do my validations by a separate validator. Why? Well, because the domain object itself (in my opinion) should not be concerned on how it validates its state, but that it has a state with data. The purpose of the business object's validation concerns cross boundaries with the concerns of the business rules. Therefore, I have found an approach where my validation is done before population, if it validates, then I populate my domain model object.

On this principle, we are building the validator plugin on ColdBox, that will be used to create validation rules and validation objects. Anyways, please go ahead and try all approaches!! Great post!!

I like where you're going with this Jason, and you've already got come interesting suggestions in the comments. I very much like being able to ask my Business Object (BO) to validate itself, but i don't want it to actually know _how_ to validate itself, so I inject a Validator Object (VO) into the BO (using a factory). That allows me to call validate() on the BO, but all the BO does is turn around and call validate() on the VO. It gives me the API I want, but keeps things encapsulated. When the BO calls validate() on the VO, it passes itself in, so when the VO goes to perform the actual validations it's able to ask the BO for the data. Again, this keeps things encapsulated. I could change the implementation of either my BO or VO and nothing would break.

I do something similar to what Luis describes: I validate during population (to catch any datatype errors), and then I also validate after population (to check business rules). This allows me to report all validation failures back to the user.

Regarding the issue of a form field that is not persisted, I would take a different approach depending on what the actual requirements are. If it's really just about program flow then i'd argue that that isn't a validation at all, and would probably handle it in the controller. If it's about a property that doesn't need to be persisted in the database, like a "verify password" field, I usually create a property in my BO (via a getter and setter) for that, which allows me to validate it just like any other property. To me that is still an example of a business rule, and therefore it makes sense to have the rule defined in the business object.

In answer to your question about how the validator learns the rules, I use metadata for that. All of the business rules are defined once in the metadata, and are injected into the VO by the factory. The VO then knows how to perform all of the server-side validations, and can also generate all of the client-side validations, from the one set of metadata.

I'll be very interested to see where you go, as there are definitely many different ways of doing this.