How should MVVM Toolkit be used to elegantly derive a property in the ViewModel from multiple properties in the Model (responding to changes in the model)? It seems that the NotifyPropertyChangedFor attribute cannot be used for properties outside of the ViewModel class.
Related question:
By using the NotifyPropertyChangedFor attribute or plain-vanilla "propertychanged" event handlers, you are basically defining that a property B influences property A. At the same time, in the getter of property A you are defining how B influences A, by defining an expression A = F(B). This is unnecessarily redundant. The fact that A = F(B) already implies that any change of B should result in a notification to update A. You could easily make the expression A = F(B) and forget to add the response to change of B, and you will not find it out until testing.
SolSoft.DataBinding tried to solve this, at the price of more complex Model classes:
https://www.nuget.org/packages/SolSoft.DataBinding/
In this case you have a single statement for each derived property in the constructor of your viewmodel. The consequence is that the model classes need to know which properties may influence properties in the ViewModel classes, by exposing property wrapper objects as properties as well. This makes the model classes unnecessarily complex.
Are there better ways to do this using MVVM Toolkit? If needed, can we think of any new features for the toolkit to make this work?
How should MVVM Toolkit be used to elegantly derive a property in the ViewModel from multiple properties in the Model (responding to changes in the model)? It seems that the NotifyPropertyChangedFor attribute cannot be used for properties outside of the ViewModel class.
Related question: By using the NotifyPropertyChangedFor attribute or plain-vanilla "propertychanged" event handlers, you are basically defining that a property B influences property A. At the same time, in the getter of property A you are defining how B influences A, by defining an expression A = F(B). This is unnecessarily redundant. The fact that A = F(B) already implies that any change of B should result in a notification to update A. You could easily make the expression A = F(B) and forget to add the response to change of B, and you will not find it out until testing. SolSoft.DataBinding tried to solve this, at the price of more complex Model classes: https://www.nuget.org/packages/SolSoft.DataBinding/ In this case you have a single statement for each derived property in the constructor of your viewmodel. The consequence is that the model classes need to know which properties may influence properties in the ViewModel classes, by exposing property wrapper objects as properties as well. This makes the model classes unnecessarily complex. Are there better ways to do this using MVVM Toolkit? If needed, can we think of any new features for the toolkit to make this work?