I think I know the answer to my question on how this will need to work but am wondering if anyone else has solved this in a different manner.
We use CSLA 4.x in production and CSLA 4.5 in development presently.
We are growing the ability for clients to be able to indicate: "we want these additional fields (propertyinfos) to be required". Obviously, each client will have a different configuration of what those fields are.
On the client side, overriding AddBusinessRules would probably work; but on the server side, this cannot work - there is only one "static" Organization class for all clients to be using.
I'm contemplating adding a business rule for every property info (dynamically) that may or may not end up enforcing "requiredness". It would look at the current client's definition on whether it should be required and then treat it as such. If it's not required, the rule just passes.
I don't necessarily see this as a problem performance wise - I can't see it being a burden to check - for example - 40 business rules of this fashion even if CheckRules() for all properties is called.
I also don't really see an alternative approach if I want the propertyinfos to "just work".
Any input appreciated - thanks!
A collegue of mine mentioned RuleSets and it looks like those are static once established... we will be providing an interface to change which fields are required within the application so that wouldn't quite work. (It doesn't look like you can "re-initialize" an object's business rules by wiping them out and re-initializing them once the object has called AddBusinessRules once)
Two additional option:
1. Use RuleSets - IE: Create a ruleset for each "client" and load all rules on the server for all clients. In DataPortal_Create/DataPortal_Fetch set the RuleSet name to the client id. However. this will not provide a dynamic behavior.
2. Hook into the PropertyHasChanged event and run an ObjectLevel rule that checks ALL the custom required field. Less obtrusive (just add one rule and override PropertyHasChanged and then check all the possible additional properties). This is similar to using a 3rd party rule engine and check rules in an external engine.
Your suggested solution will also work fine and will provide a dynamic behavior - per property.
Thanks for your response, Johnny. Will the object level rule provide any way to mark properties as having broken rules? Right now we have our nice little propertystatus controls next to each entry field and the expected behavior will be for me to have those lit up showing where information is required and hasn't been supplied.
My guess is that the object level rule won't provide for this, right?
Both ObjectRules and PropertyRules can add broken rules to other properties.
Just be aware that any existing broken rules from this rule is removed before the rule is rerun again - so you need to provide a complete set of BroenRules for each run - no difference here between ObjectRules or PropertyRules.
This is supported from CSLA 4.3 (IIRC).
I think I follow - sounds like I'd have to iterate across all 40-50 property values whenever the rule is run if I had 40-50 property infos, and then add broken rules for any invalid ones each time. So each property change could be a little heavier weight.
I ended up adding a boolean to my BusinessBase for "ApplyConditionallyRequiredRules" - which, when true for a business object, will add a conditionally required rule for each nullable typed propertyinfo (including string). This rule basically looks into a managed set of information by client about what properties are required by what clients and examine its value *if required* to determine its validity.
Seems to work just fine. Thanks again for your input.
Copyright (c) Marimer LLC