WPF bindings and MVVM are nice when they work, but can become a royal pain when they don’t. This is especially annoying when you create bindings in code, because then you don’t get the automatic tracing which is enabled for bindings in XAML. Any error is silently swallowed. Here’s what I found out (waiting to confirm it with MSDN documentation and independent small tests):
– if you have a one-way binding and someone changes the target value not using the binding, the binding will be deactivated
– if you have a two-way binding, someone changes the target value not using the binding, and something goes wrong updating the source (e.g. converter’s ConvertBack() method throws an exceptions), your binding will be deactivated.
Deactivated bindings look like they are there, but they don’t do anything. Effectively, binding stops working, and it is often very difficult to know exactly why. If you created the binding in code, you can look at the status of the binding expression. If you created the binding in XAML, getting to its status is much more difficult. Also, it is not possible (to the best of my knowledge) to put a breakpoint when binding status changes: there is no data breakpoints in managed code, and I could not .NET source debugging to work for WPF bindings for whatever reason. I could see things like DependencyObject, but not BindingOperations.
Bottom line: binding system sometimes fails silently. Detecting and debugging those failures can be very time consuming and difficult.