Greetings... 1- quoting the documentation about "Validation per field":

It is recommended you do only small tests in Validator classes and place the bigger business logic rules in own classes which consume entity objects, or extend the derived entity classes in the two class scenario (use one of the Two class scenario generator config files to generate these derived classes).

why this recommendation ?

2- for "Validation for Entity" the documentation explains that

The generated code performs entity-wide validation, if an IEntityValidator instance is present in the entity, when the entity is saved or when Validate() is called.

does this meen that IEntityValidator validation is NOT performed when entity objects are retreived from the presistance storage ?

OMAR

omar wrote:

Greetings... 1- quoting the documentation about "Validation per field":

It is recommended you do only small tests in Validator classes and place the bigger business logic rules in own classes which consume entity objects, or extend the derived entity classes in the two class scenario (use one of the Two class scenario generator config files to generate these derived classes).

why this recommendation ?

Because in the validation classes generated you are not able to retrieve the entity object.

2- for "Validation for Entity" the documentation explains that

The generated code performs entity-wide validation, if an IEntityValidator instance is present in the entity, when the entity is saved or when Validate() is called.

does this meen that IEntityValidator validation is NOT performed when entity objects are retreived from the presistance storage ? OMAR

Correct, as they are checked when they're saved. So in theory, the data in the database is consistent.

Greetings,

Correct, as they are checked when they're saved. So in theory, the data in the database is consistent.

But what if I had to modify my validation logic at a later stage in the system so that the Data in the DB would violate the new rules. I know that optimally I should perform data-scrubbing to clean up the stored data so that it would adhere to the new rules, BUT the in some cases the situation allows for allow the possibility of the persistent data to being in-valid as long as the user is warned of this whenever the data is retrieved from the DB and the data can't be modified/saved unless it is adhering to the new business rules?

Shouldn’t we have a Boolean switch to turn ON data validation check when data is retrieved from the DB...?

OMAR

omar wrote:

Correct, as they are checked when they're saved. So in theory, the data in the database is consistent.

But what if I had to modify my validation logic at a later stage in the system so that the Data in the DB would violate the new rules. I know that optimally I should perform data-scrubbing to clean up the stored data so that it would adhere to the new rules, BUT the in some cases the situation allows for allow the possibility of the persistent data to being in-valid as long as the user is warned of this whenever the data is retrieved from the DB and the data can't be modified/saved unless it is adhering to the new business rules?

Interesting point. I have some questions though If data changes in the database, and I load it again, and it violates some rules set at that point, it also did that when it was in the database. So modifying rules means also modifying data in the database, or am I mistaken?

Also what to do when the rules are violated when the entity is loaded? To me, the entity's data is then not usable and should be modified or deleted, as the entity can't be used by the system.

Shouldn’t we have a Boolean switch to turn ON data validation check when data is retrieved from the DB...?

I find it an interesting point of view. I'll add it to the todolist for the next upgrade.

The feature I want is the option of triggering the entity validation event after the field level validation event is triggered.

i.e. a field validation for zipcode goes through

then I want the entity validation code to be processed where I can determine if a valid product is selected for that zipcode.

This provides seperation of individual field structure validation vs. validation across the entity.

Currently if I want this behavior I must manually trigger the entity validation call.

John

Also good suggestion. Not hard to implement either. I'll add it too.

If data changes in the database, and I load it again, and it violates some rules set at that point, it also did that when it was in the database. So modifying rules means also modifying data in the database, or am I mistaken? Also what to do when the rules are violated when the entity is loaded? To me, the entity's data is then not usable and should be modified or deleted, as the entity can't be used by the system.

Not really. What we are doing is implementing a rules manager (or more accurately a BrokenRules collection) for every entity. A property in the entity (IsValid) flags the presence of any broken rules in the entity's broken rules collection. It goes something like this:

1- a call to entity's (Validate) method would populate the BrokenRules collection instead of throwing an exception

2- a call to an entity's (Validate) should also recursively call the (Validate) method of any contained child Entity (1:1) or any contained child collections (1:n)

3- The entity would behave and live normally. The only stipulation is that if an attempt to save (or in some cases Delete) the entity while its (IsValid) is false, then we would throw an exception

This provides great flexibility for the UI developer. In the UI, when an entity is retrieved from the DB, the BL validates it (call its Validate) and its BrokenRules collection gets populated (because it is NOT valid under the recently modified business rules).

A UI list-control binded to the entity's BrokenRules collection would show any broken rules for this entity (much better than displaying a long messagebox that must be dismissed before the user can edit the entity to adhere to the new rules)

If the UI still attempts a save for this entity, the exception thrown by the BL layer would buble up and show in the UI.

We have even extended this framework to include TypeOfBrokenRule (DenySave, DenyDelete, Warning, Information) and overloaded both (Validate) and (IsValid) properties so that the CRUD operations could validate and check: - Save: Validate(TypeOfBrokenRule.DenySave) then check IsValid(TypeOfBrokenRule.DenySave) before saving - Delete: Validate(TypeOfBrokenRule.DenyDelete) then check IsValid(TypeOfBrokenRule.DenyDelete) before deleting

This gave us the flexibility of adapting to changing BusinessRules and knowing that all future edits would adhere to these changes...

OMAR

Hmmm...sounds similar to something I just built. Although not aimed directly at your purposes, we also built a rules engine that abstracts the rules from the entity's properties and allows a semi-technical user to build the rules using a GUI. Then, using attributes (and what I think is Aspect Oriented Programming, not really sure about that), I associate each control on a form to a property on an entity.

A control validator object then iterates through each control tagged with the attribute, adds a common delegate to the control's "Validating" event, and associates an ErrorProvider control with it as well. Bam! Presentation level validation! Then, when the user attempts to save the entity, each of the properties are fed to the rules engine and if any fail, the entity is not allowed to save. And this is all using the same set of rules.

The great thing about keeping the rules in the database (as we do) is that we can easily build rule sets and version the rules if necessary. Dunno if this type of thing is useful to you, but thought I'd mention it.

Jeff...

omar/jeff: sounds like a great idea. I'll try to add better ways to make this possible, for example by always calling certain methods on entity instantiation/fetch etc. It's more of a selfservicing thing I think, as with Adapter you can outsource it to a BL class which also controls the adapter for example.

So in short: interceptor support for the various states of an entity.