Properties passed into Business Rule Constructor seem to automatically be Dependent/Affected Properties

[mtavares628]

I've noticed this issue which ends up causing the same rules on my object to be run over and over. Basically if I pass properties (besides the PrimaryProperty) to the constructor of my rule (Rule A), and that passed in property is used as a PrimaryProperty in some other rule (Rule B), then Rule A gets called again whenever Rule B has been called. I would expect this to happen if I added the property to the AffectedProperties list for the rule, or added a Dependency rule between the 2 properties, but I'm not doing that.

Here is a sample that recreates the behavior. If you set a breakpoint on ExecuteAsync of the IDRule below, then it will get called twice when CheckRules is called.

[Serializable]
    public class Root : BusinessBase<Root>
    {
        public static readonly PropertyInfo<string> NameProperty = RegisterProperty<string>(nameof(Name));
        public string Name
        {
            get => GetProperty(NameProperty);
            set => SetProperty(NameProperty, value);
        }

        public static readonly PropertyInfo<Csla.SmartDate> ReferenceDateProperty = RegisterProperty<Csla.SmartDate>(nameof(ReferenceDate));

        public string ReferenceDate
        {
            get => GetPropertyConvert<Csla.SmartDate, string>(ReferenceDateProperty);
            set => SetPropertyConvert<Csla.SmartDate, string>(ReferenceDateProperty, value);
        }

        public static readonly PropertyInfo<int> IDProperty = RegisterProperty<int>(nameof(ID));

        public int ID
        {
            get => GetProperty(IDProperty);
            set => SetProperty(IDProperty, value);
        }
        


        protected override void AddBusinessRules()
        {
            base.AddBusinessRules();
            BusinessRules.AddRule(new ReferenceDateRule(ReferenceDateProperty));
            BusinessRules.AddRule(new IDRule(IDProperty, ReferenceDateProperty));

            //BusinessRules.AddRule(new MyRule { PrimaryProperty = NameProperty });
        }

        [Fetch]
        private void Fetch() 
        {
            using (BypassPropertyChecks)
            {
                Name = "Test";
                ReferenceDate = DateTime.Today.ToShortDateString();
                ID = 1;
            }
            BusinessRules.CheckRules();
        }
    }

public class ReferenceDateRule : Csla.Rules.BusinessRuleAsync
    {
        //IPropertyInfo IDProperty;

        public ReferenceDateRule(IPropertyInfo primaryProp) : base(primaryProp)
        {
            InputProperties = new List<IPropertyInfo>() { PrimaryProperty };

        }

        protected override async Task ExecuteAsync(IRuleContext context)
        {
            // breakpoint vvv
            context.AddSuccessResult(false);
        }
    }

    public class IDRule : Csla.Rules.BusinessRuleAsync
    {
        IPropertyInfo ReferenceDateProperty;

        public IDRule(IPropertyInfo primaryProp, IPropertyInfo referenceDateProp) : base(primaryProp)
        {
            ReferenceDateProperty = referenceDateProp;

            InputProperties = new List<IPropertyInfo>() { PrimaryProperty, ReferenceDateProperty };

        }

        protected override async Task ExecuteAsync(IRuleContext context)
        {
            // breakpoint vvv
            context.AddSuccessResult(false);
        }
    }

Is this by design? And if so, then how can I create rules with multiple properties, and prevent the rule from being called multiple times if the secondary (non-PrimaryProperty) has it's own set of rules? I can't use the Target object either, since my rules need to be Async for Blazor.

[Chicagoan2016]

I know CommonBusinessRule, which inherites from PropertyRule, has 'CanRunAsAffectedProperty'
You could implement something similar in ASync version.

[rockfordlhotka]

Using this run code:

using Csla;
using Csla.Configuration;
using Microsoft.Extensions.DependencyInjection;

var services = new ServiceCollection();
services.AddCsla();
var provider  = services.BuildServiceProvider();
var dp = provider.GetRequiredService<IDataPortal<Root>>();

var root = await dp.FetchAsync();
root.ID = 123;
root.ReferenceDate = DateTime.Today.ToString();

I'm seeing the IDRule run three times.

Twice due to the CheckRules call during fetch and once when the ID property is set.

It doesn't get triggered when the reference date is set.

Why CheckRules is running it twice isn't clear to me.

[mtavares628]

@rockfordlhotka and @jonnybee, has any thought been given to this situation so that properties added to a rule aren't automatically set as a dependent/affected property? I'd like to see this incorporated into CSLA 8, since the performance with running async rules many times is not great. Thanks.

[mtavares628]

So in looking at this some more, I have a question and some possible solutions.

Could we have things run the other way in which the Input Properties act as a trigger for that particular rule, instead of triggering the rules for the other Input Properties? To me this would cut down the same rule being triggered multiple times due to the affected properties, but still only trigger for the properties that truly affect it.

Here are some of my proposed options:

• Add a boolean flag to the rule named something like InputPropertiesRunAsAffectedProperties. You can default it to true for backwards compatibility, but if false, it doesn't run the routine to add all of the input properties as affected properties.
• Add a TriggeredProperties collection to the rule. Any of the properties added to it would then trigger that rule in addition to the Primary Property.

So the CheckRulesForProperty function would look something like this:

                private List<string> CheckRulesForProperty(Csla.Core.IPropertyInfo property, bool cascade, RuleContextModes executionContext)
        {
            var rules = from r in TypeRules.Rules
                        where ReferenceEquals(r.PrimaryProperty, property)
                          && CanRunRule(ApplicationContext, r, executionContext)
                        orderby r.Priority
                        select r;

            BrokenRules.ClearRules(property);
            var firstResult = RunRules(rules, cascade, executionContext);

            // Run any rules that are triggered from this property
            var triggeredRules = from r in TypeRules.Rules
                                 where !ReferenceEquals(r.PrimaryProperty, property)
                                       && r.PrimaryProperty != null
                                       && r.TriggeredProperties != null
                                       && r.TriggeredProperties.Contains(property)
                                       && CanRunRule(ApplicationContext, r, executionContext)
                                 select r;

            // Not sure if we should cascade here or not, or whether we need to use the rules result for anything
            RunRules(triggeredRules, false, executionContext);

            if (CascadeOnDirtyProperties)
                cascade = cascade || firstResult.DirtyProperties.Any();
            if (cascade)
            {
                // get properties affected by all rules
                var propertiesToRun = new List<Csla.Core.IPropertyInfo>();
                foreach (var item in rules)
                    if (!item.IsAsync)
                    {
                        foreach (var p in item.AffectedProperties)
                            if (!ReferenceEquals(property, p))
                                propertiesToRun.Add(p);
                    }

                // add PrimaryProperty where property is in InputProperties
                if (InputPropertiesRunAsAffectedProperties)
                {
                    var input = from r in TypeRules.Rules
                                where !ReferenceEquals(r.PrimaryProperty, property)
                                      && r.PrimaryProperty != null
                                      && r.InputProperties != null
                                      && r.InputProperties.Contains(property)
                                select r.PrimaryProperty;

                    foreach (var p in input)
                    {
                        if (!ReferenceEquals(property, p))
                            propertiesToRun.Add(p);
                    }
                }
                // run rules for affected properties
                foreach (var item in propertiesToRun.Distinct())
                {
                    var doCascade = false;
                    if (CascadeOnDirtyProperties)
                        doCascade = firstResult.DirtyProperties.Any(p => p == item.Name);
                    firstResult.AffectedProperties.AddRange(CheckRulesForProperty(item, doCascade,
                                                                         executionContext | RuleContextModes.AsAffectedPoperty));
                }
            }

            // always make sure to add PrimaryProperty
            firstResult.AffectedProperties.Add(property.Name);
            return firstResult.AffectedProperties.Distinct().ToList();
        }

I'm not 100% sure whether you would want to cascade on the Triggered Property Rules or not. My guess would be not, since you are only running those rules that the changed property has affected. Maybe I'm way off base here, but this would cut down on a lot of the rule re-running if I only triggered the rules that pertain to that specific property rather than running every rule for any affected property. @rockfordlhotka I welcome your thoughts, and why this may not be a good idea.

[ossendorf-at-hoelscher]

Anything new here?
We are having issues with having AsyncRules executed concurrently for a non-dependent property from which we only need the value.

[ossendorf-at-hoelscher]

Furthermore if you have an async rule and the properties A, B, C. Where A is the primary property, B & C are input properties. And also C is an affected property.

When you do the following:

// f.B is any value not set here
f.A = "Abcd";
f.C = "cdef";

The async rule is executed concurrently and as far as I can see. Always the first rule execution (triggerd from the assignment of A) wins the race even though I set C explicitly (which triggers the rule again).

[mtavares628]

Issue #3616 addressed this. @rockfordlhotka added a check to the CheckRulesForProperty code that only runs the rule on the Input Property if that property was actually changed (in the dirty properties collection). This definitely cut down on the multiple running of rules for me. The fix is in CSLA 8 prereleases.

I'm still considering putting in a pull request for my TriggeredProperties concept, because I think it allows a user full control over when that rule will get called right within the rule itself, but I haven't gone down that road of trying that concept out yet.