This is similar to what I wanted to achieve in an earlier post, but is a bit different, so I figured a new post was in order.
I have a class whose internal state should change based on another property of the class being set.
What is best practice way to do this in CSLA?
I thought a rule was the way to go, but I do not want the rule class itself to be able to manipulate an object's internal state.
The only thing I can think of now is putting the logic in a property setter, and setting my other properties via (BypassPropertyChecks) within the setter. Then on DataPortal_Fetch, call LoadProperty for the particular property in order to bypass this custom business logic in the setter.
Any other thoughts on how I might leverage the CLSA to achieve this type of behavior?
What do mean by changing the objects internal state?
I'd still recommend to make a custom BusinessRule for that logic and set the properties.
I would think "object state" means one or more property values - and this is exactly the kind of think a rule should be doing. This is what rules are for.
Great! So how does a rule class change the internal state of a class without exposing it publicly?
Perhaps I'm not using the new Rules correctly, but on execute, it seems that I have to cast the RuleContext.Target to the appropriate type, and then access it's properties that way. But I can't get at it's internal state this way if it's not exposed publicly, which is what I want to avoid.
CSLA 4 has input and output properties from rules. That technique allows for a couple things.
Prior to CSLA 4 you need to use one of these technqiues:
Clearly I think the CSLA 4 model is better though, or I wouldn't have put so much work into the redesign
I'm using CSLA 4. So when the rule executes, do I invoke the AddOutValue() method to set the object's internal state?
That is correct, and also add that property to the affected properties list - that way the appropriate data binding events will be raised, etc.
Copyright (c) Marimer LLC