Why have minimal user/handwritten code and do everything in XAML?

Question

I feel the MVVM community has become overzealous like the OO programmers in the 90's - it is a misnomer MVVM is synonymous with no code. From my closed StackOverflow question:

Many times I come across posts here about someone trying to do the equivalent in XAML instead of code behind. Their only reason being they want to keep their code behind 'clean'. Correct me if I am wrong, but is not the case that:

XAML is compiled too - into BAML - then at runtime has to be parsed into code anyway. XAML can potentially have more runtime bugs as they will not be picked up by the compiler at compile time - from incorrect spellings - these bugs are also harder to debug. There already is code behind - like it or not InitializeComponent(); has to be run and the .g.i.cs file it is in contains a bunch of code though it may be hidden. Is it purely psychological? I suspect it is developers who come from a web background and like markup as opposed to code.

EDIT: I don't propose code behind instead of XAML - use both - I prefer to do my binding in XAML too - I am just against making every effort to avoid writing code behind esp in a WPF app - it should be a fusion of both to get the most out of it.

UPDATE: Its not even Microsoft's idea, every example on MSDN shows how you can do it in both.

Answer 1

I've never heard of anyone suggesting to put everything in XAML.

In fact, that would be a terrible idea, IMO.

The problem, historically, came from Winforms apps having logic in their code behind that didn't belong there, because it was logic. That's where the importance of VM comes from. It allows you to isolate the parts that tie together the View to the Model.

Therefore, the View is left to only handle what is does best, which is UI.

Now, if you happen to have situations where your UI requires code, then by all means go for it and put it in your code behind. However, I would say that for 95% of the scenarios out there, you will most likely be better off leaving the UI in the markup file, and if you need some code behind, it's probably some logic that you're trying to write out that is more appropriately left to the View Model. Exceptions to this are things such as Behaviors, but they are separate animals entirely, and require a special place (i.e. not in your code behind).

Answer 2

To directly answer your question, and assuming that when you say "code" that in every instance you are referring specifically to code-behind (code that is on a visual control class), the reason is so that your user interface can be entirely implemented and manipulated in Blend, using only one technology. The assumption is that your UX designers aren't developers and don't want to work in code, and that they are layout and XAML experts as opposed to coding experts. If you implement everything without code-behind, you can give those kinds of designers the tools they need to work entirely in their language.

It provides a clean separation between imperative programming and declarative design.

It's the driving reason for the existence of "behaviors" in Silverlight and WPF - instead of plunking some code into the code-behind, make a behavior its own little reusable module. If you do, Blend gives you the benefit of literally being able to drag and drop it onto a control. Now, instead of having some one-off moving part to an otherwise all-in-XAML control, you have abstracted the moving parts into a nice container that can be manipulated using designer tools.

Answer 3

In my experience, this often comes down to trying to use complicated logic in XAML triggers in order to keep it out of the code-behind, when the better, simpler approach would be to put that logic in neither -- it belongs in the view-model.

Answer 4

One of the biggest advantages to doing everything you can in xaml is that it keeps all of the behavior in one place. Every time the developer has to jump between the xaml and the code it becomes more difficult to understand it.

I've been on a WPF team that didn't make reduction of code-behind a priority. There were more than a few times that debugging was much more difficult because some event handler was manipulating the control and it wasn't immediately apparent because the behavior was scattered around in two files.

That said, I believe you are right to think that sometimes you are better off compromising on the design principle. Some things are very difficult to do in xaml. I've spent hours or even days trying to get a behavior to work in xaml that I could have done in much less time by using code-behind. I've come to treat code-behind as a last resort, but I would never tell someone that they should never use it. It's just another tradeoff that a good engineer needs to understand.

edit: From the comments it sounds like my post is being interpreted as arguing against xaml. My intent was to argue the opposite. Pure xaml is always preferable because it keeps all of the behavior in one place. A mix of xaml and code-behind can get convoluted, so minimizing code-behind is ideal. Xaml is preferable to pure code-behind for lots of reasons. WPF and Silverlight are designed to be written in xaml.

Answer 5

I have only very superficial knowledge of XAML, but it baffles me that the compiler won't detect typos.

The basic difference is, that XAML is declarative, while C# for example is imperative.

Simply put:

Pane p = new Pane(200, 100);
Button foo = new Button("foo");
Button bar = new Button("bar");
p.addChild(foo);
p.addChild(bar);

vs.

<Pane width="200" height="100">
    <Button label="foo"/>
    <Button label="bar"/>
<Pane>

The upper code really creates a hierarchy by sideeffects, while the lower one simply declares it. It is also worth noting, that while for example the addChild method might be renamed, the child-parent-relationship is at the core of the semantic model and is represented just as such in the declarative snippet. It is very far from the implementation, which allows for much optimization underneath, such as lazy instantiation, completely transparently.
Declarative programming has a number of advantages. It's more concise, expressive and very close to your model. I would go as far as that it is preferable.

However, this doesn't mean, you should try to punch everything into XAML. C# has many high level constructs that allow a declarative style.

In the end, you want your code to be short and easy to read. So if you can achieve the same thing in C# with less code than in XAML, using C# is logical. Keep in mind that, however, XAML code is more "portable" in the sense that it is much less vulnerable to changes in the components used, abstracting the .NET framework away (for example the details of how bindings are implemented).