Question

I wasn’t able to find a discussion on this topic but I think its pretty important so theres a big chance it exists, so Ill be gladful to read.

In our viewmodel setters for properties we can check if provided value is equal to current value and only notify in that case, or we can ignore the check and set & notify right away.

While this check appears pleasing as it saves some resources when “refresh” on VM doesn’t cause View redraw it can also present some bad effects when View is a little more complicated and has some code behind which either can’t be put in VM or when putting it in VM is too difficult compared to leaving it in View.

So generally from my experience with MVVM I can think of scenario when this check prevented some code from working as expected. So currently I am thinking that this check is a dangerous thing and generally not worth the benefit of a saving redraw sometimes.

Also sometimes this check can be used as a substitute for better program logic when for example there are 2 properties on VM that actually are closely connected like, say string & object representation of some entity. So when one is set for example string, inside it calls an object setter too if validated correctly, and this equality check saves situation from infinite loop of object <-> string setters, but in that case I think its much better to introduce a flag that is checked in setter and doesn’t call another if it is not needed, when call to say object setter came from call to string setter.

I think that this check is mostly used for scenario I just described which I think isn’t exactly a good reason to perform the check.

So how should we code our setters?

Edit: well just to give a scenario, the simplest and most stupid one would be this: if we have a OneWay binding to View from VM and for some reason there exists some handler in View codebehind that changes View directly, causing it to become unsynchronized with VM, refreshing VM wont help. Of course its obvious that in that case we should be calling VM setter that is bound , but I think in some cases scenario can be more complicated and advanced where resolution becomes less transparent. So scenario is stupid but having a check would prevent from correct behavior. Ill think more on a real world example where its not so easy to resolve but probably will require some time..

Answer 1

In my personal experience I have found this check very useful and I always put the equality check in the setter to make sure that if there is no need to refresh the binding value then I should not call the property change and should not force view to refresh the value when it is not required at all.

Talking about your scenario where equality check is causing you trouble, I think there must be something odd in the scenario or most probably you might be approaching something incorrectly otherwise I have used MVVM a lot and haven’t find such a scenario in my case. Even if there exists a scenario where it may might make sense to not to do equality check, I won’t stop using equality checking because of a small minor issue I am facing in some few cases. I will try to do some workaround in that particular problematic case to avoid the problem rather then not using the equality check in the setters