views:

84

answers:

1

I am working with Windows Forms Databinding, implementing interfaces like IDataErrorInfo. In order for this to work, the domain(or business) object is allowed to be in an invalid state. In fact, the domain object needs to retain the invalid value as the user entered it for IDataErrorInfo to work properly. As long as the object isn't persisted in invalid state, we're ok.

However, as the subject line suggests I was wondering whether there is a difference between contraint and validation. The former would prevent the user from making the change AT ALL, the later is the type of validation I've described above.

Let me explain - if you have a collection of Person and Person has a SSN property. The PersonCollection is keyed on SSN, meaning in the collection, there cannot be two Persons with the same SSN. If we allow temporary invalid state on Person, we introduce a situation where there are two Persons with duplicate SSN in the collection, albeit temporarily. This can lead to issues where another object working with PersonCollection, looking for a Person object with the duplicated SSN, getting two objects.

So, to me, it seems that certain type of validations need to be constraints rather than (post-change) validations.

Thoughts?

A: 

To take your example, part of your validation for the Person should be a rule that checks that its SSN is not a duplicate (by the way : in case of duplication, how do you know which one is right ?).

If you run into trouble, because your PersonCollection is in fact an IDictionary keyed by SSNs, wait until a Person is validated before you add it to the collection. An object should be invalid temporarily enough to let you do that.

For more information on validation, check my answer to Business Objects, Validation And Exceptions.

Mac