c# - Avoiding Duplicate RaisePropertyChanged for Cascading Read-Only Properties

Question

I have several Read-Only Properties in my View Model that are referenced by the View and some of them are dependent on one/more other Read-Only Properties (in the same View Model) which are ultimately dependent on one/more Read/Write Properties (in the same View Model). I've only seen the following pattern in samples to make sure PropertyChanged Event is Raised for all potentially affected Properties, but I don't like duplicating all those RaisePropertyChanged Calls.

I suspect I should instead be adding a Handler to the PropertyChanged Event of my View Model and in that Handler, for each Property which has dependent Properties, call RaisePropertyChanged on only the Properties that directly (vs. also the ones that indirectly) depend on that Property. How can I avoid duplicating all those RaisePropertyChanged Calls?

public bool MyReadOnlyPropertyAA1
{
    get
    {
        return MyReadOnlyPropertyA1 [&& MyReadOnlyPropertyB1 ...]
    }
}


public bool MyReadOnlyPropertyA1
{
    get
    {
        return (MyPropertyA == (Some Value)) [&& MyPropertyB == (Some Other Value)) ... ]
    }
}

public MyPropertyAType MyPropertyA
{
    get
    {
        return myPropertyA
    }
    set
    {
        myPropertyA = value;
        RaisePropertyChanged(nameof(MyPropertyA));  
        RaisePropertyChanged(nameof(MyReadOnlyPropertyA));
        RaisePropertyChanged(nameof(MyReadOnlyPropertyA1));
        RaisePropertyChanged(nameof(MyReadOnlyPropertyAA1));
        ...
        RaisePropertyChanged(nameof(MyReadOnlyPropertyAA...1));
    }
}


public MyPropertyBType MyPropertyB
{
    get
    {
        return myPropertyB
    }
    set
    {
        myPropertyB = value;
        RaisePropertyChanged(nameof(MyPropertyB));  
        RaisePropertyChanged(nameof(MyReadOnlyPropertyA));
        RaisePropertyChanged(nameof(MyReadOnlyPropertyA1));
        RaisePropertyChanged(nameof(MyReadOnlyPropertyAA1));
        ...
        RaisePropertyChanged(nameof(MyReadOnlyPropertyAA...1));
    }
 }

Answer 1

I use both approaches depending on the property relationship.

If it would be logical that changing one property would trigger a change in another, I just leave the property change code in the setter.

public string PropertyA
{
    get { return propertyA; }
    set
    {
        myPropertyA = value;
        RaisePropertyChanged(nameof(PropertyA));  
        RaisePropertyChanged(nameof(IsPropertyAValid));
        ...
    }
}

However if the two properties are not logically related, then I will use the PropertyChange handler :

private void MyClass_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
    switch(e.PropertyName)
    {
        case "PropertyA":
            RaisePropertyChanged(nameof(PropertyB));
            break;
    }
}

The reason for this is I want no special logic in my property setters. To me, they should be fairly generic, stuck in a #region tag, and collapsed to be forgotten about.

If two properties are logically related and you would expect changing one to potentially alter the value of another, then the RaisePropertyChange code can be left in the setter.

But if they are different, and in the future myself or another dev were looking at the code and would potentially not know/understand that there's a dependency between the two, I put the change in the class's PropertyChange event handler so it's easy to find and/or change if necessary.