Why keep code behind 'clean' and do everything in XAML? [closed]

Question

What is the benefit of keeping code behind 'clean'?

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.

Answer 1

1. The designer perspective

UIs are often built by designers using designer tools (expression blend and friends). If I have this kind of worklow, it simply just doesn't work if you put a significant amount of UI-related code in codebehind. At least that's the experience we made. The code and the behavior/functionalty it defines is inacessable to the designer:

• For the most part that code is only executed at runtime and not while designing. So the designer doesn't see the full story while designing.
• Designers are not programmers and only have limited (if at all) porgramming skills so they most likely are incapable of refining the UI behavior defined there.

Additionally we have made the experience that it gets quite hard to find a way to provide mocked designtime data (d:DesignInstance, d:DesignData, d:DataContext) for the designer to work with if there is codebehind.

2. The developer perspective

UI-related code in codebehind (I am assuming here that it is unnecessary to talk about the odds of putting domain logic in codebehind) is code that is not reusable. It is code that is bound forever to that one specific UserControl/Window/Page. If I for example instead would write a custom attached property or a behavior I get resuablity plus I make our desginers happy because they can use it too.

All code I put in codebehind is code that is hard to test. Of course it mostly doesn't get easier just by putting it in XAML or in a custom attached property. But depending on what type of functionality I put in codebehind there are cases where I could have encapsulate it in testable (reusable) classes.

Defining appearance and behavior in XAML tends to be less (as opposed to the questioners argument) error prone than in code. I just can't make as many mistakes in XAML as I can in code. If I did something wrong chances are that I see it right away in the designer/visual studio. Of course the tools still can improve here. Infact if I additionally use ReSharper those "incorrect spelling" miskates in XAML that the questioner mentions are almost impossible to make. I get that code highlighted right away. I am sure the standard tools will pick this up. XAML is the preferred way to define the UI in WPF and a much higher effort has been made by microsoft to assure that it works as expected than using code. Infact I have already spent quite some time debugging memoryleaks and runtime exceptions on code that did UI related stuff and could have been moved to XAML with little or no extra effort.

If I ease up on the codebehind abstinence there is a higher risk that I write clutterd and bad code. Sometimes it is just to tempting to put a quick hack in codebehind. We have sufferd from the consequences more than once.

Using codebehind is rarely really necessary. Once you get used to ViewModel driven UIs there is alomst never a justifyable necessity for codebehind. It doesn't take much effort to put it somewhere else. So why bother?

Answer 2

I think it has to do with

• Testability - it stems from the idea of keeping the Views thin ala the ModelViewController / MVP / MVVM patterns for building GUIs. That way the view just has controls which are bound to a backing presenter class, which can then be easily tested without having to involve the GUI. You can achieve a remarkable degree of confidence just by testing via the presenters. It is significantly faster than testing via the UI too.
• Moving to declarative programming as compared to imperative programming - XAML is declarative programming. You don't need to test XAML markup. Also it is MS code that is more or less guaranteed to work and remain working. So you can be quite certain that initializeComponent won't break with a check-in that you just made. So theoretically, you could get by without ever testing your views - provided your code-behind has no custom/hand-written logic.