Skip to content

Evaluate business object rules

This operation is the framework's validation pipeline behind IsValid, CheckRules, and IDataErrorInfo. It clears stale rule failures for the identifier being checked, runs registered rules in strict severity order — errors before warnings before informational rules — stopping error escalation as soon as one level fails, and leaves the resulting broken-rule state available to both calling code and UI data-binding consumers.

Field Value
Operation ID OP-CORE-002
Trigger Caller invokes IsValid or a business object/collection calls CheckRules([ruleIdentifier]).
Inputs Business object or collection instance and an optional property/group rule identifier.
Outputs Boolean validity plus refreshed broken-rule, warning, and informational state.
Primary components clsBusinessBase.IsValid, clsBusinessBase.CheckRules, clsBusinessCollectionBase.IsValid, clsBusinessCollectionBase.CheckRules, clsRulesManager.CheckRules
Entry point SAIF.Framework.Core\V1\BaseItems\clsBusinessBase.vb

Steps

  1. Start validation from IsValid or CheckRules.
  2. clsBusinessBase.IsValid clears previously propagated rules and calls CheckRules() (BR-001, BR-002).
  3. clsBusinessCollectionBase.IsValid validates child objects first and can stop after the first invalid child when ValidateAllChildren = False (BR-001, BR-002).
  4. Apply the deleted-object branch before running object rules.
  5. If a business object is marked deleted and ValidateOnDelete = False, clsBusinessBase.CheckRules clears broken rules and skips execution entirely (BR-001).
  6. Otherwise it forwards the request to Rules.CheckRules(Me, identifier) (BR-001).
  7. Reset stale failures for the requested rule identifier in the rules manager.
  8. clsRulesManager.CheckRules clears previously recorded failures for the requested property/group before re-evaluating that identifier (BR-001, BR-002).
  9. Execute error rules in ordered levels.
  10. Level 1 rules run first; level 2 rules run only if level 1 produced no failure; level 3 rules run only if level 2 also passed (BR-001).
  11. Each rule delegate is invoked through ProcessRule, which turns a failed result into a clsBrokenRule entry (BR-001, BR-002).
  12. Execute non-error rules only after all error levels pass.
  13. Warning rules run next.
  14. Informational rules run after warnings (BR-001).
  15. Propagate child messages when the target is a collection or when helper validation is used.
  16. clsBusinessCollectionBase.CheckRules calls PropagateChildMessages() so children with Rules.PropagateMessages = True contribute failures to the collection (BR-002).
  17. ValidateChildObject() and ValidateChildObjects() also re-run child validation and propagate failures back to the parent (BR-002).
  18. Surface the refreshed validation state to consumers.
  19. IDataErrorInfo.Error returns the concatenated object-level error text (BR-002).
  20. IDataErrorInfo.Item(columnName) returns property-specific error text, and the count/message properties expose error, warning, and informational summaries (BR-002).

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([IsValid or CheckRules]) --> Delete{Deleted and<br>ValidateOnDelete = False?}
    Delete -->|Yes| Clear[Clear broken rules]
    Delete -->|No| L1[Run level 1 rules]
    L1 --> Pass1{Passed?}
    Pass1 -->|No| Surface[Expose broken rules]
    Pass1 -->|Yes| L2[Run level 2 rules]
    L2 --> Pass2{Passed?}
    Pass2 -->|No| Surface
    Pass2 -->|Yes| L3[Run level 3 rules]
    L3 --> Pass3{Passed?}
    Pass3 -->|No| Surface
    Pass3 -->|Yes| Info[Run warning and informational rules]
    Clear --> Surface
    Info --> Surface
    Surface --> EndOk([Return validity state])

Failure and edge-case behavior

  • A deleted business object can intentionally skip validation entirely when ValidateOnDelete is disabled — this is a deliberate shortcut, not an omission, so a deleted-and-invalid object will still report as valid in that configuration.
  • A collection can stop validating remaining children as soon as the first invalid child is found when ValidateAllChildren = False, so a True collection result in that mode does not guarantee every child was actually checked.
  • Re-checking one rule identifier clears only the prior failures recorded for that identifier before re-evaluating it, so stale broken-rule entries for other identifiers are left untouched.

Sources

  • SAIF.Framework.Core\V1\BaseItems\clsBusinessBase.vb
  • SAIF.Framework.Core\V1\BaseItems\clsBusinessCollectionBase.vb
  • SAIF.Framework.Core\V1\BusinessRules\clsRulesManager.vb