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

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

You should keep all your code clean, and moving the work from the code behind to the XAML is not keeping it clean it is just moving where it is located. You should put the code (and XAML is a form of code) where it makes the most sense to put it, while attempting to follow OOD Principles as best you can.

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.

Answer 3

I think the reason why most programmers (especially those who practices MVVM) don't put in code in code-behind files is to utilize data binding in XAML, which is I think is a lot simpler than doing it programmatically. Also, maybe it is easier for developers and designers to work together using XAML (e.g. fill up with design-time data).

Answer 4

Avoiding the code-behind file should mostly be aimed at by people following MVVM. My view is this: having business logic in code behind leaves your View and ViewModel dependent on each other (directly or indirectly).

If you restrict code-behind logic to behavior of the view itself only, then you can interact fully with your application via the ViewModels. This also implies that if you manage somehow to put business logic in the xaml itself (not delegated back to the ViewModel), this is also wrong.

To answer the question more directly: I see "do everything in XAML" as bind everything to your ViewModel / all business logic in the ViewModel.

Answer 5

WPF and XAML for me is broken. Too many dynamic elements, which are checkable during runtime -- that's very bad. So use XAML all UI I know during design stage -- if the text is bold or not, wiring data, setting converters, validators, and so on.

I don't know what exactly you mean by clean code. If it is clean, I use clean code, if not -- I don't, and I don't care anyway, it seems more logical for me.

Answer 6

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 typ 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?