Business Rule AddOutValue to update a calculated field marks the object DIRTY

Business Rule AddOutValue to update a calculated field marks the object DIRTY

Old forum URL:

AbbasMalik posted on Thursday, October 03, 2013


Updating a calculated field in a business rule also marks the object DIRTY. Is there a way to avoid this?

context.AddOutValue(_QtyProperty, qty / factor);


JonnyBee replied on Thursday, October 03, 2013

Why shouldn´t it mark the object as dirty? Assuming that the rule is only allowed to run when the property is changed the object will always be DIrty - already. 

Remember, it could just as easily be a lookup filed (name, adress etc) as a calculated field. 

The proper way to exclude the field, if that is what you want, is to override IsSelfDirty in the business object and exclude the calculated properties for the IsDirty check.  



AbbasMalik replied on Thursday, October 03, 2013


I am not saving the calculated field in the database. After loading an object from the database, a rule is run to populate the calculated property. So, in this case, I don't need to mark the object as dirty.

What if I try LoadProperty() instead of AddOutValue() like this:



PurchOrdLine bo = (PurchOrdLine)context.Target;
LoadProperty(bo, _QtyTotalProperty, (qty + qtyFree) / factor);

Thanks. replied on Thursday, October 03, 2013

Hi Abbas,

I'm asssuming that you checkrules in the fetch method.

We call MarkOld() after having loaded our BO and checked the rules.

Note: this also assume that you will not save computed properties in DB.



AbbasMalik replied on Thursday, October 03, 2013

Hi Gilles

Calling MarkOld() just after the CheckRules solved the problem.

Thanks. replied on Thursday, October 10, 2013

[edit: please ignore the following comment, I was too quick the current behavior is the one expected]

Hi Jonny,

I dig a little the code of RuleContext. I do not understand the intend usage of AddDirtyProperty.

I was expecting this method to be implicitly called when using AddOutValue, I realized today that this is not the case.

I'm asking the question because I saw that recently (after 4.5.10), we now cascade automatically if there are dirtyproperties, but the CascadeOnDirtyProperties flag has no impact if we use AddOutValue.



rfcdejong replied on Monday, October 07, 2013

We use a attribute above the property which prevent it from making the business object dirty.

        public static PropertyInfo<decimal?> TotaalGeschatInkomenProperty = RegisterProperty<decimal?>(c => c.TotaalGeschatInkomen, "Totaal geschat inkomen");

        public decimal? TotaalGeschatInkomen
            get { return GetProperty(TotaalGeschatInkomenProperty); }
            set { SetProperty(TotaalGeschatInkomenProperty, value); }

this is the attribute

    public sealed class CalculatedAttribute : Attribute 
    { } 

and a custom class implementing the interface IPropertyInfoFactory is the most important

The amount of code to place is too large to paste here.
Look at the DefaultPropertyInfoFactory.cs in csla for more information.

The clue is to return a CalculatedPropertyInfo if a property is marked with IsCalculated attribute.
In a abstraction layer override LoadPropertyMarkDirty and check if the property is an ICalculatedPropertyInfo, if it isn't then don't mark it dirty.

AbbasMalik replied on Tuesday, October 08, 2013

Hi rfcdejong

Thanks for suggesting another solution ... for the timebeing I am fine with MarkClean() workaround. May be I implement it later as you suggested.

Copyright (c) Marimer LLC