Home > Uncategorized > XAML and Code Separation

XAML and Code Separation

XAML allows you to create a user interface to display and interact with data declaratively, with little or no code. Microsoft obviously wants you to create a code behind file for every XAML window or control you build, but if you can avoid that, you’ll gain some terrific flexibility in your application. XAML becomes nothing more than your presentation layer – a complete user interface definition in XML – no business logic or data access code intertwined with your UI. If your user interface is just a string of XML, you have a lot more options for deploying, maintaining, and extending that user interface beyond just compiling it into your application. Store it in a file system, store it in a database, generate it dynamically at runtime with XSL…

XML based UI technologies have come a long way over the years with technologies like XUL which powers Mozilla applications and MXML for Macromedia’s Flex. The real strength of XAML is in data binding and its tight integration with the .NET CLR, which is generally the platform of choice for business applications. With data binding, your UI elements are truly observing your underlying data which means when the data changes, the controls update automatically without any extra code. Of course, extensibility is one of the most important features of any API, and with XAML and WPF there are many options for extensibility that are in easy reach of any developer familiar with .NET.

To build the WPF extensions necessary for a loose XAML application, you will probably need to become familiar with a few things that aren’t in a traditional Windows or Web application developer’s toolkit.

  1. Reflection
  2. Application tracing
  3. Command interface (System.Windows.Input.ICommand)

Reflection will allow you to make components that are highly configurable, which means they are very reusable in many different scenarios. You can adjust the configuration at runtime using CLR properties and WPF dependency properties. Just about everything in XAML uses reflection to some degree, so becoming familiar with the technology is very helpful.

Probably the most frustrating thing about declarative data binding is there is no source code so you can’t easily debug your application to find out why something isn’t binding or updating. However, .NET has plenty of built in tracing features that will help to explain why things aren’t working as expected.

One of the first problems that occur when trying to use loose XAML is that event handlers can only exist in a code-behind class, which you won’t have in a XAML only scenario. With WPF, Microsoft added the System.Windows.Input.ICommand interface, which is a way to receive input from your application without event handlers. ICommand has two methods, CanExecute(object):bool and Execute(object):void, and you can use command binding on buttons, hyperlinks, and menu items to send data to any ICommand implementation in the form of a CommandParameter.

Once you’ve mastered these three technologies, you’ll likely never want or need code-behind again, and you can achieve complete seperation of presentation and application logic. Then it is on to the real extensibility of WPF, with Dependency Properties, Attached Properties, and Markup Extensions. Dependency Properties allow you to create special properties on your own classes that support data binding. Attached Properties allow you to create special properties on a static class that you can “attach” to any Dependency Object, which means you don’t always have to extend a class just to give it more properties. And in a pinch, when you find there is a little feature missing in WPF, like getting the index of an item in a WPF ItemTemplate, you can use a Markup Extension, which will be replaced by the XAML parser with whatever data is returned by its ProvideValue method at runtime.

Categories: Uncategorized
  1. Clay Ver Valen
    July 26, 2011 at 7:01 pm

    Given the name of your blog, I thought you might like to take a look at an MMV framework I created that lets you use loose XAML yet easily use data binding, routed commands and event handlers in a C# file. Pure loose XAML, not even a reference is required between the View and View Model projects.

    The framework is stable, but this is v1. So if you’ve got any feedback I’d appreciate hearing it.

    – Clay

    • loosexaml
      August 3, 2011 at 8:40 pm

      Clay – I’m taking a look at it and giving it a test drive. I will get back to you shortly.

  2. Clay Ver Valen
    August 1, 2011 at 10:45 pm

    Thought you might be interested in this: http://xtrememvvm.codeplex.com/

    It is a framework designed to work with loose XAML but still have all the advantages of a code-behind (e.g. data binding, routed commands and event handlers).

    – Clay

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: