Vibrant discussion about CSLA .NET and using the framework to build great business applications.
Unless my expectation of what should happen is wrong, I have a potential bug.
I have a business rule that is a mutator (i.e. changes the value of properties), specifically I have the rule trigger on the primary property called PropertyA. In the rule I let CSLA know that there will be an affected property (called PropertyB), and then in the rule execution I set the value of the property using context.AddOutValue(...).
The problem is that after the rule is triggered and therefore executes, that the FieldManager.IsFieldDirty( PropertyB ) remains false, despite the property change that came from the rule's context.AddOutValue( ... ),
Below is an example of the rule (sorry if it seems contrived, but only because I'm taking out unrelated "fluff"):
private class PropertyAChangeMutatesPropertyB : BusinessRule
public PropertyAChangeMutatesPropertyB() : base( PropertyAProperty )
AffectedProperties.Add( PropertyBProperty );
protected override void Execute( RuleContext context )
var target = (MyBusinessObject)context.Target;
// If PropertyA is dirty, then we need to set a default for PropertyB
if ( target.FieldManager.IsFieldDirty( PropertyAProperty ) )
// Default value for property
context.AddOutValue( PropertyBProperty, DateTime.Now );
And here's the code that doesn't behave as expected:
var myBusinessObject = MyBusinessObject.Get();
myBusinessObject.PropertyA = new DateTime( 2000, 12, 31 ); // Trigger the Rule
// The Rule does execute
// Wrong result
var shouldBeDirtyButIsNot = myBusinessObject.FieldManager.IsFieldDirty( PropertyBProperty );
Am I wrong to expect that the "AffectedProperty" that is changed by context.AddOutValue( PropertyB, ... ) should be setting the IsDirty state for the field?
Thanks and happy CSLA coding!
I think that AddOutValue in background calls LoadProperty. There is no SetProperty in BusinessRule. Only thing that you can do is casting context.Target to your BO and than directly set its properties. Unfortunately, if you have some read only properties, or your rule is async than you are stuck. So I gave up using rules for anything more complex.
Thanks for reporting this. I will look into it when I get home from vacation.
My initial respone is to consider it a bug. If a property is changed it should be dirty.
The challenge is that the rule engine uses the non-generic LoadProperty to provide support for private field properties and this method does not mark the field as dirty.
Jonny Bekkum, Norway
If this is a bug. Will it be fixed?
It's on my todo list for CSLA 4.5. Not completed or checked in yet.
Checked in to repository now.