Change state based on a property changing

AaronH posted on Monday, August 02, 2010

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?

Thanks!

JonnyBee replied on Monday, August 02, 2010

Hi,

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.

RockfordLhotka replied on Monday, August 02, 2010

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.

AaronH replied on Tuesday, August 03, 2010

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.

Thoughts?

Thanks!

RockfordLhotka replied on Tuesday, August 03, 2010

CSLA 4 has input and output properties from rules. That technique allows for a couple things.

It allows CSLA to read/load the property values without the properties needing to be public
It provides a consistent programming model for sync and async rules - in both cases the rule is operating against a copy of the property values

Prior to CSLA 4 you need to use one of these technqiues:

Make the property public (not desirable - not just because of scope, but because of triggering rules, authz, etc)
Use an interface to access the value (better - less obviously public, and your interface implementation can bypass rules on get/set)
Make the rule a private rule within the business class (arguably best, because the rule can interact with the object's state directly - it is part of the object after all)

Clearly I think the CSLA 4 model is better though, or I wouldn't have put so much work into the redesign Smile

AaronH replied on Wednesday, August 04, 2010

Thanks.

I'm using CSLA 4. So when the rule executes, do I invoke the AddOutValue() method to set the object's internal state?

RockfordLhotka replied on Wednesday, August 04, 2010

That is correct, and also add that property to the affected properties list - that way the appropriate data binding events will be raised, etc.