CSLA 4.1 BusinessRule - AffectedProperty not Dirty according to FieldManager

CSLA 4.1 BusinessRule - AffectedProperty not Dirty according to FieldManager

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

Jaans posted on Thursday, July 07, 2011

Hi all

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!


mesh replied on Friday, July 08, 2011

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.

JonnyBee replied on Saturday, July 09, 2011

Hi Jaans,

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.

GoGO replied on Monday, April 09, 2012

Hello Jonny,

If this is a bug. Will it be fixed?

JonnyBee replied on Monday, April 09, 2012

It's on my todo list for CSLA 4.5. Not completed or checked in yet.

JonnyBee replied on Sunday, April 15, 2012

Checked in to repository now.


Copyright (c) Marimer LLC