Currently, when a user fills out a data entry winform I validate the data when the user enters information from one field to the next. I also validate the data , as a whole, when the user clicks on the Save Button. Now all this validation logic is in the ui.

This does not seem to be the correct way of doing validation. I use the Adapter scenario and Manager classes to instanciate my entities and collections and to perform all the CRUD functions.

So, any suggestions on how to better do the field-to-field validation and the overall Save validation to make better use of reuse?

Thanks,

Fishy

Validator classes?

Devildog74 wrote:

Validator classes?

How would the Validator class on an Entity help with the overall validation that would span multiple entities? I could see it if the entity contains enough related collections to make a decision that the overall data is valid, but, I don't see how it would work if you had multiple entities that needs to be compared. Or, how field to field validation would be performed.

Now, saying this, I may have a total misunderstanding of what you mean by Validator class.

Could you perhaps elaborate on this?

Thanks,

Fishy

Fishy,

You can validate at each layer of the application.. UI -> BL -> DAL -> DB or you can validate at the perimeter of the application. Where and how many times the data is validated really depends on a number of factors, including security requirements, development cost, maintenance cost etc...

In general, its a good idea to validate data at ALL external interfaces and as soon as possible inside those interfaces. "Defending in depth" dictates that you validate again at each layer...

Can you elaborate on your app's requirements a little more?

I have this Assignment Maintenance form. It has assignment name, due date, groups (associated collection), subject area (1:1), sub skills (collection). If the user enters a non-school day for the date due I want an error generated (field validatation). When the user clicks Save I want something (either my ui or perhaps the AssignmentManager) to look at all the data and determine if any errors exists. If they do then I want the ui to report it and let the user fix the problems.

So, how would you handle something like this? Validate in the AssignmentManager or the ui or somewhere else?

What about the field to field validatation? Write the code directly in the ui or somewhere else?

Thanks for your help,

Fishy

My opinion on this is that validation should be (relatively) orthagonal to the specific layer you're working with - it crosscuts across all layers, as Marcus suggested.

Thus, validation should be wrapped into a separate set of functionality that can be referenced at whichever layer you want. In my "spare" time I'm working on developing validation as a set of rules that can be applied to a) a field, b) an entity, and c) a process. As each of these items are nested under the next, calling a validate method at a higher level, say at the process level, results in all validations to fire for all entities and fields underneath encapsulated by it.

In the GUI, due to this orthagonality one can use AOP or simply attributes to associate a rule with a given control. Then, when the control's Validate event fires, you can trap the event and validate the contro's value against the rule specified in the attribute - and this rule is the same rule used when "Save" is clicked, or when the BL wraps the data for persistence. Consistency, reusability; it's all good.

In early attempts I was able to successfully hook GUI controls to rules using attributes, and associate an ErrorProvider control to provide for visual cueing to the user - as the user tabbed off a field, the rule was checked, and if it failed, a little red icon lit up next to the control with a tooltip describing the violation. So, I'm fairly comfortable that the concept will work when completed.

There are also some validation frameworks out there. I didn't like what I saw as many of them depended too heavily on XML files for the rule sets, but you may find them interesting...

Jeff...

jeffreygg wrote:

My opinion on this is that validation should be (relatively) orthagonal to the specific layer you're working with - it crosscuts across all layers, as Marcus suggested.

Orthagonal - that's an interesting word. Had to look it up.

Yes, being able to breakup the rules to whatever degree you want and then being able to implement them at different levels seems to be a worthwhile goal.

Thanks,

Fishy