CSLA Validation Version 3.8.2

CSLA Validation Version 3.8.2

Old forum URL: forums.lhotka.net/forums/t/8789.aspx


Lazaro posted on Friday, April 09, 2010

Hello,

We are migrating from CSLA version 1.3.0 to 3.8.2 and we need some help with the new broken rules validation model.

We had created a method called CheckFinalBrokenRules in the BusinessBase class that gets called by the IsValid property before checking the BrokenRules Collection count and it is implemented/overwritten by the inheriting business objects. This CheckFinalBrokenRules method was created to validate rules that were expensive, “complex” or “not possible to validate” in properties (too many properties to monitor and methods to call in too many different objects).

 Some of the rules that we have in the CheckFinalBrokenRules method include rules that depend on: siblings objects’ states or just their existence, parent object’s state (which could depend on the state of child collections or other related objects), database query for validation, complex code with iterations and referencing other objects, etc. We sort of see the rules that we put in the CheckFinalBrokenRules method as Object/Entity level rules not so much properties specific rules.   We limit the rules that are validated in the CheckFinalBrokenRules method to those that are really justified to be there given what we mentioned above (we try to keep the checking of rules in the set of the properties whenever possible).

How do we achieve this in the new CSLA version?

 

 

 

 

 

 

 

rsbaker0 replied on Friday, April 09, 2010

I'm not familiar with the rules implementation prior to CSLA 2.0, but perhaps you could leverage the ability to associate one or more rules to a "pseudo" property (e.g. the rules implementation doesn't care if the property name actually corresponds to a valid property).  Rules associates with a pseudo-property won't typically ever be called in response to a property change. However, note that they do get called if ValidationRules.CheckRules() is called without a property name, notably during DataPortal_Create() in the default implementation, so that case would need to be addressed.

So, it might be that you can just associate your expensive rules with a pseudo-property -- maybe even call the pseudo-property "CheckFinalBrokenRules"  , and in your IsValid method, call ValidationRules.CheckRules("CheckFinalBrokenRules").

RockfordLhotka replied on Saturday, April 10, 2010

There was no real validation rules concept in CSLA 1.x - only broken rules tracking - so your question is not uncommon for people moving from 1.x to something more current.

CSLA 3.8 has a fairly powerful business rules system with numerous features, and you should learn how they all work before deciding how to migrate. They are discussed (mostly) in the Expert 2008 Business Objects book and I walk through all the features with sample code in the Core 3.8 video series.

The most common way to handle expensive rules is to set their priority to be 1 or higher. That way they'll only run if all priority 0 rules pass. The priority/short-circuiting feature is specifically designed to solve most expensive rule issues.

In the rare case that priorities aren't enough, you can attach rules to a fake property - rules are attached to a property by IPropertyInfo or by string name. Just attach the expensive rules to a fake property name. Then you can call CheckRules("FakeName") when you want to run those specific rules.

Copyright (c) Marimer LLC