[ ] IMHO, things like bindings and commands should be done in the code behind, because XAML doesn't provide for any logic. While you can declare bindings in the XAML, you can't do it conditionally.
Not sure what you mean on this one. I tend to declare most bindings in XAML - if the binding fails then it fails silently (i.e. no exception is thrown) and that, oddly enough, can be beneficial - if the binding makes sense then it's used; if it doesn't then the control is disabled......you can use that behaviour to your advantageHow would you do this in XAML?
if condition A
bind to class X
else
bind to class Y
Again, I think binding is the realm of the developer not the designer, and XAML is the realm of the designer, not the developer. I find it MUCH easier to do things like commands and bindings in the code behind.
While you might be able to do
some things like this in XAML you can't do it all, which means some of your logic is now in the XAML and some in C#, which would get ugly fast.
Also, I don't know about you, but I
WANT to know when a binding fails. Why would you want a silent failure to go unreported?
Everything makes sense in someone's mind
public class SystemCrasher :ICrashable
In addition, an integer field is not for irrational people