WPF -- Where do you draw the line between code and XAML?

Question

I'm a long-time C#/.NET programmer but totally new to WPF and the System.Windows.Controls namespace and XAML. The more I learn about it the more I realize that you can do pretty much all of your GUI initialization and event handling glue in either XAML or in code (say C# code or VB.Net code).

My question is to those who have been working on WPF for longer and ideally those who have shipped apps with it -- where did you find was the best place to 'draw the line' between XAML and code? Did you use XAML wherever you could? Only where interfacing with non-coding UI designers?

Any tips in this area would be extremely helpful to myself and other coders who are just getting into WPF programming and are kind of paralyzed by all the choices we can make!

Answer 1

One tip is to not declare event handlers in XAML. Instead, name your elements and attach events handlers in the code-behind. That helps keep a clean separation between the designer and developer.

Answer 2

Another tip is to separate XAML into functional and aesthetic. Developers would typically work in the functional XAML whilst designers care primarily about the aesthetic. This keeps the functional XAML very easy to grok, which is important because developers often need to edit such XAML. Aesthetic XAML is typically edited by designers using tools, so its neatness and verbosity is less of an issue.

I did a bit of a blog post on this a while ago here.

Answer 3

When building UserControls I try to Xamlize as much as possible.

One tip I found in the field is that creating ControlTemplate and DataTemplates by hand is really a pain in the ***... I always write those in XAML....

Answer 4

One thing that I would look at is the model-view-view model pattern. It is a very elegant pattern which naturally separates everything into nice buckets ... including your xaml.

For example, it helps you keep a clear boundary between the developer and the designer and even allows for test driven development.

There is a whole bunch of info out there on it, but I would start with John Gossman's blog posts:

• http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx
• http://blogs.msdn.com/johngossman/archive/2005/10/09/478894.aspx
• http://blogs.msdn.com/johngossman/archive/2006/02/26/539598.aspx
• http://blogs.msdn.com/johngossman/archive/2006/02/27/540304.aspx
• http://blogs.msdn.com/johngossman/archive/2006/03/04/543695.aspx
• http://blogs.msdn.com/johngossman/archive/2006/04/13/576163.aspx

Update: Just want to point people to another StackOverflow post with lots of good info on M-V-VM in it.

Answer 5

When you follow a proper pattern like Mode-View-ViewModel you will get opportunity to do more on XAML side and less on code behind. Maximize the usage of RoutedEvents and Commands in WPF code.

Answer 6

As others have suggested, try following the Model-View-ViewModel pattern. However, it's OK to put stuff in the codebehind! The rule is that if it's "View" related, you put it in the Xaml or the codebehind (whichever is more convenient for you). If it's more business logic related to how the user interacts with the system, then it belongs in the ViewModel. If it's just business logic not concerned with interaction, it belongs in the Model.

Examples of each would be:

• Model: defines a property called ModifiedDate that stores the last time it was modified.

• ViewModel: converts the ModifiedDate into an enumeration property called ModifiedAge, based on when it was modified: Yesterday, In the Last Week, In the Last Month, In the Last Year, etc.

• View: converts the ModifiedAge property to a background color where more recently accessed data is highlighted bright yellow, and less recently accessed data is more of a beige-khaki-gray that your designer insists is called "Meadow Lark Lilly Flowerpot".

Answer 7

I would say use as much xaml possible, using Binding, commands, styles, templates etc. I had to support functionality of saving and loading templates using XAMLReader/XAMLWriter and it more easier for controls having more xaml.

Answer 8

Don't lose sight of the fact that XAML is code. It's declarative and all that, but it's still a programming language. In fact, it goes through a conversion to C# or Visual Basic before it's turned into IL for the .NET compiler to chew on.

I'll echo Scott Whitlock's comment: MVVM is a great way to separate concerns and focus on architectural details. It's really, really OK to put stuff in your code-behind, especially the stuff he describes. If you don't have a requirement to separate designer from developer, then adapt the MVVM pattern to your specific needs; don't try to force yourself to be pure or idealistic about it.

It's also perfectly OK to put calls to your ViewModel's methods right in the View code behind, if you don't need the flexibility of commanding with ICommand classes. Or if you know the View you're making will always be bound to the ViewModel class you're making. Or you could take things a step further, define an interface for your ViewModel, and bind only to implementations of that interface. Then you can still swap out the ViewModel whenever you want.

Stuff like that.