Validation concepts

The validation infrastructure provided by DevForce is made up of a collection of interoperating validation components that are both easy to use and capable of handling sophisticated scenarios. The developer can:

Capabilities

• Generate validity checking into business objects automatically via the DevForce “Object Mapper.
• Write rules of any complexity. The developer can draw upon pre-defined rules (required value, range check, field length) or write custom rules of any complexity, including rules that compare multiple fields and span multiple objects.
• Validate any kind of object, not just objects that derive from base business classes.
• Trigger validity checking at any time such as upon display, before save, or when setting properties. The engine can fire “pre-set” to block critically errant data from entering the object or fire “post-set” to accommodate temporarily invalid values. The UI can inspect the engine for rules of interest, fire them, and adjust the display accordingly. It could color a text box, for example, or hide a portion of the form until applicable criteria were met.
• Display a localized message in the UI without special programming using localized resources delivered by a .NET standard or custom Resource Manager. 
• Classify validation results by type. Code that inspects validation results could display just the “validation failed” message but it might also show warnings or “ok” messages and it might supplement the message be re-directing the application focus to the offending object and property. Each rule returns a rich, extensible object with all the information necessary for the developer to deliver a helpful response.
• Discover rules in the code or retrieve them at runtime from a central store. The engine automatically discovers rules in the code and can acquire rules defined externally in configuration XML, a database, or some other store of rules. The application can inspect, add, and remove rules at any time.
• Leverage rules inheritance. Rules defined in base classes propagate to their derived classes where they are “inherited” or overridden.
• Adjust validation behavior based on a custom validation context. The developer must have the flexibility to convey custom information to the validation process to cope with the variety of situational factors that arise in real applications.
• Inspect and intervene as the engine validates. The application can monitor the engine’s progress and interrupt, modify, or terminate a validation run at any point.
  
  

“Verification” vs.“validation”

The DevForce validation mechanism is called “verification” and all of its components are named with some variation on this word. We mean to try neither your patience nor your vocabulary. We would call our offering “validation” if we could.

However, Microsoft uses the term “validation” throughout .NET. It appears in Windows Presentation Foundation (WPF) and Windows Workflow Foundation (WWF) namespaces and in the Enterprise Library as well. Microsoft also uses the following class names:

ValidationError, ValidationErrorCollection, ValidationManager, ValidationResult, ValidationRule, ValidationStatus, ValidationType

IdeaBlade is integrating DevForce with Microsoft’s WPF and WWF. You are likely doing the same. We will all become confused if we cannot easily distinguish among the same or very similar names.

So “verification” it is. We will continue to say “validation” when we speaking in general terms; we will use the term “verification” (and its variants) when we refer specifically to the DevForce classes located in the IdeaBlade.Verification namespace.

What about WPF and Silverlight Validation?

We can’t leave this digression without a parting comment about validation in Microsoft’s Windows Presentation Foundation.

WPF validation concentrates on presentation of validation results within a WPF user interface. This is a vital aspect of any validation strategy. At present, most applications punish the user for the developer’s own design failings. We need better UIs and better means to guide users rather than humiliate them.

DevForce’s “verification” concentrates on the validation process. It complements WPF by producing the rich validation results necessary to deliver an effective user experience. We will address the integration of these mechanisms in a separate document.