XAML or C# code-behind

I don't like to use XAML. I prefer to code everything in C#, but I think that I am doing things wrong.

In which cases it is better to use XAML and when do you use C#? What is your experience?

Solution 1:

Creating an entire window in C# can be a mess of code. The best thing about WPF is that XAML allows you to separate your design from your logic, making for much easier-to-read code.

I'll use C# when I need to create dynamic controls, but I tend to keep my general design, static storyboards, styles, datatemplates, etc. in XAML.

Solution 2:

Check out this video on MVVM in WPF. If you want wrap your head around how to organize a WPF application vis-a-vis what goes in XAML, code behind and other abstractions, this is a great place to start.

Solution 3:

You can certainly go too far with XAML. Those who want their entire user interface (including logic, event handling relationships, etc) defined in XAML are probably missing the point.

The aim of XAML is to provide a common format for determining how things should look. It should just be a description of how to lay things out, how to color and style them visually.

There is really very little point in trying to use it as a replacement for other aspects of C#, because C# has a permanent head-start in terms of programming features - reuse (defining types and functions), referring to variables, procedural programming, and even declarative or functional styles.

Personally I really like throwing together a UI with a Linq expression!

The ultimate absurdity was reached by a sample I saw where they used workflow actions as the children of a button to supply the Click handler, so the whole program was in XAML. It sounds "cool", but the problem was that it was significantly more ugly and unreadable than the equivalent C# or VB.NET program, and so everything that is ready to use in C# has to be replaced by a more verbose, flaky equivalent. Nothing has actually been gained by this translation to an uglier syntax - it's the same program only more hideous. XML is a poor basis for the syntax of a general programming language. Start with the fact that the greater-than symbol has to be written as >!

In a parallel universe, Microsoft released C# 3.0 before they finished XAML. The XAML team adopted C# 3.0 object/list initializer syntax instead of XML as their syntax. And this whole debate never happened.

Solution 4:

My experience is that some things are far quicker to do in C#, while most are quicker to do in XAML. When it takes 5 lines of C# code to do what a single line of XAML code can do, it's pretty easy for me to choose which is better.

Solution 5:

Basically, XAML is meant for expressing visual-design, C# is meant for expressing logic.

Any visual design should be done in XAML, any logic should be implemented in C#.

- This enables giving the visual design to a designer to play on without worrying about changes to the logic and even replacing the entire visual design at run time using loose-XAML.

- This also means you could replace either the logic or the visual-design without "breaking" either.

- The connection between the two should be done with data bindings and with command bindings.

The practice I use is:

1. Define the model (the business data object model) in separate C# code.

2. Define the constant parts of the view (the constant parts of the graphical user interface, e.g. the windows, menus, ...) in XAML (preferably use Blend and not VS for this).
* Do not define styling (colors, fonts, ...) here.
* Do not write event handlers for buttons (in most cases) in code-behind-the-XAML, use command-bindings instead.

3. Define how the model is presented within the view (the GUI for viewing/editing the data objects) using XAML "ResourceDictionary"s located in separate files.

- Write using blend then add bindings to XAML using VS (Jetbrains' Resharper add-on for VS will help with binding expressions).

- If the object types are not known during design-time you can use "loose-XAML" and place the XAML in a folder which can have files added to / edited within without recompiling.

4. Create a connection between the model and the view (a controller/view-model) in C# which:
* Creates views as necessary (for dynamics objects)
* Data-binds the view to the model (sets view's DataSource as the relevant object within the model)
* Implements the commands
* Command-binds the view to the command implementations within itself

5. In Application.xaml delete the StartupUri="MainWindow.xaml" and add Startup="ApplicaitonStartUp" instead.
Within the ApplicationStartUp() event handler:
* Load any loose-XAMLs you have
* Create the controller
* Create the main window
* Create the model
* Connect controller to model and main window
* Show main window
* (Save model, controller and main window into private fields here to make sure they are all kept alive)

6. Add styling (colors, fonts) to a separate XAML file under a ResourceDictionary (using blend for this or purchase a ready made XAML theme/skin file).