I just wanted to know what the pros and cons are of using what the user BlueCell calls "soft contraint validation". Here is a link to his forum thread about trying to get this to work in LLBLGen:

http://llblgen.com/tinyforum/Messages.aspx?ThreadID=14244&StartAtMessage=0&#79435

I posted about the lack of direct support for this pattern in my own thread in the Bugs section, and thought it would be more appropriate for a general discussion as this lack of direct support clearly is not a bug, but by design.

The idea of what BlueCell calls "soft-constraint validation" is that field values should be able to be set, and marked as invalid. This is opposed to the more traditional idea of never allowing an invalid field value to be set at all.

I have for a long time been of the mindset that it should be ok to set a field value to an invalid value as long as that invalidity is dependent on the state of the entity graph: ie, you changing the entity graph (add/remove of an entity, or changing of another field value) can make this field value valid again.

LLBLGen thinks of this problem in another way completely. If a field is set to a value which breaks a rule which is dependent on the state of the graph, this is not considered to be an invalid field value. At best, this is an invalid entity altogether, but this is only the case if the invalidity is dependent on the state of another field in the same entity. If the validity of a field is dependent on the state of the graph outside of the entity that owns this field, then this is something else entirely...not to be dealt with with the normal validation mechanism in the framework.

Here is a simple example of the soft constraint validation being useful: I have a product table (entity). I have a rule that says no two products can have the same .Name property. There exists a product with .Name="Dark Table". I want to add another product and name it "Dark Table" and rename the original one "Really Dark Table". By using soft-constraint validation, I can do the .Name setting of the two products in any order, the framework does not constraint this. For example, the user can:

1. Name the new product "Dark Table" and receive notification that this is invalid given that there is another product with this name.
2. Rename the other product "Really Dark Table" which will remove the invalid state of the new product.

I can also do the renaming in the other order, causing no invalid fields. If using traditional validation, I force the user to do the renaming in a specific order:

1. Rename "Dark Table" to "Really Dark Table"
2. Name new product "Dark Table".

This is just one reason I can think of to justify soft-constraint validation. I think there are probably other reasons, but the preceding is the only one I personally have cared about.

I saw that Frans says this is a bad idea altogether. He mentioned that there could be problems when dealing with foreign keys. I think I see this problem he is talking about...for example, you user should never be allowed to set a foreign key to a value that doesn't exist in the related table.

So, I was wondering what other issues may come up if using this pattern. If this is so whole-heartedly rejected as a "bad idea", there's got to be something I am missing.