You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When looking at a graph, e.g. a ViewModel bound to a UI, the IChangeTrackingService provides useful insights on the actual status of the graph. For example it's easy to detect if it is changed or not.
What the actual infrastructure lacks is the ability to better understand what type of changes happened. For example the actual changes stack of a property could be the following:
a -> b -> c -> a
and the question in such a scenario is: is the property changed?
From the IChangeTrackingService perspective the answer is yes, from the end user perspective it might be no because the actual property value is exactly the same as the original one.
In a ViewModel the above can be easily obtained by using the following snippet:
bool TryGetOriginalValue<T>(string propertyName, out T value)
{
var valueChange = this.GetTrackingService().GetChangeSet().OfType<PropertyValueChange<T>>().FirstOrDefault(x => x.PropertyName == propertyName);
if (valueChange != null)
{
value = valueChange.CachedValue;
return true;
};
value = default(T);
return false;
}
bool IsPropertyChanged<T>(Expression<Func<T>> property)
{
T originalValue;
if (TryGetOriginalValue(property.GetMemberName(), out originalValue))
{
var actualValue = this.GetPropertyValue(property);
return !originalValue.Equals(actualValue);
}
return false;
}
that is handy for a single property but can become quite costly for the whole graph.
The IChangeTrackingService can have this knowledge built in.
One option could be to allow a query such as the following:
which could return the information if the property is changed and if the property value is changed compared to the original one. Finally an overload allowing a comparer to be plugged in to satisfy non default comparison logic.
Following this approach we could also enhance the actual behavior of the GetEntityState method on the IChangeTrackingService interface adding the above logic to a full entity.
As a final step the advisory can become smarter, on demand.
The text was updated successfully, but these errors were encountered:
When looking at a graph, e.g. a
ViewModel
bound to a UI, theIChangeTrackingService
provides useful insights on the actual status of the graph. For example it's easy to detect if it is changed or not.What the actual infrastructure lacks is the ability to better understand what type of changes happened. For example the actual changes stack of a property could be the following:
and the question in such a scenario is: is the property changed?
From the
IChangeTrackingService
perspective the answer is yes, from the end user perspective it might be no because the actual property value is exactly the same as the original one.In a
ViewModel
the above can be easily obtained by using the following snippet:that is handy for a single property but can become quite costly for the whole graph.
The
IChangeTrackingService
can have this knowledge built in.One option could be to allow a query such as the following:
which could return the information if the property is changed and if the property value is changed compared to the original one. Finally an overload allowing a comparer to be plugged in to satisfy non default comparison logic.
Following this approach we could also enhance the actual behavior of the
GetEntityState
method on theIChangeTrackingService
interface adding the above logic to a full entity.As a final step the advisory can become smarter, on demand.
The text was updated successfully, but these errors were encountered: