Separation of Concerns while programming WPF with XAML
By now we are all hearing rumblings around Windows Vista, WinFX, WPF (Avalon) and XAML. WinFX is the new approach to designing applications for Windows Vista (formerly codenamed Longhorn), but beta versions of the libraries are already available, consisting of the Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF) and Windows Workflow Foundation (WWF). One of the common threads around the architecture will be that substantial portions will be based on XAML, the Extensible Application Markup Language.
XAML is an extension of XML which allows one to create and initialize .NET objects. There is a very close mapping between XAML markup files and the actual .NET/WPF object definitions and anything that is created in XAML could also be coded in C# as usual. The clear win here is the ability to design a Windows GUI in markup form, completely separating out things such as business logic, persistence (data-binding) and event handling.
From Windows Presentation Foundation” (Chris Sells and Ian Griffiths)
the look is something that you’re likely to want handled by someone with artistic sensibilities (a.k.a “turtleneck-wearing designer types”), whereas the behavior is something you’ll want to leave to the coders (a.k.a
“pocket-protector-wearing engineer types”) Ideally we’d like to move the imperative “look” code into a declarative format suitable for tools to create with some drag ‘n’ drop magic. For WPF, that format is XAML.
Sure, you could come close with a strict MVC design earlier, but it is very easy (at least in the small amount of GUI programming I’ve done, rather than service/persistence development) to end up embedding logic, persistence and routing into your forms.
To give an example of the benefits of XAML, the following C# code to build a simple window:
public class MyWindow : Window {
public MyWindow() {
this.Title = "My WPF Window";
// add a button
Button button = new Button();
button.Content = "The Button Text";
this.AddChild(button);
}
}
can also be written in XAML:
<Window x:Class="MyWindow">
xmlns="http://schemas.microsoft.com/winfx/avalon/2005"
xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"
Title="My WPF Window"
>
<Button x:Name=”button”>The Button Text</Button>
</Window>
That obviously barely scratches the tip of the tip of iceberg, but I think you get the idea. Your GUI is laid out in XAML separate from the logic and persistence that you implement in the C# classes backing these forms.
Now I’m all for separation of presentation from behavior and this seems like a large improvement over the Winforms style of relying on your C# code to manage all form widgets (similar to my first C# example). However, it is also possible to set up your databinding and event handling code inside the XAML files. And as I’ve started to work on learning WPF, I’ve noticed a disturbing tendency in various materials and publications to encourage pushing as much as possible into XAML. It’s not uncommon to find statements in assorted blogs and learning materials such as,”Well here’s how you do
It seems to me that as we progress through 2006, the development community will gain more and more experience building larger non-trivial apps with WPF and WinFX. Best practices will come out (maybe they are already there) regarding proper separation of concerns between GUI layout and backing control, event and persistence code. And a lot of this will depend on the implementations of WPF designer tools which are again out in beta (Cider and Sparkle) because in the end, who really wants to handcode all of that XAML? They will be generating the XAML for us and it’ll interesting to see their approaches to that task.
And maybe I’m just grouchy because as one of those “engineer types” (sans pocket-protector), I tend to like my OO code and have a hard time parting with it!
December 3rd, 2005 at 11:57 am
I agree; the tendency to do it all in the XAML is something that has bothered me too. The only reason that a world in which all code lives in XAML instead of living in the form’s C# would be (slightly) better is that XAML is more declarative than imperative. That being said, I do believe that the patterns that will be successful will be those that treat the XAML as declarative view definition, with a .NET model behind it.
December 5th, 2005 at 11:19 am
ugh, as someone who has written XSLT and attempted to develop applications that users have to interact with I find this a bit unnerving. Coding logic in an XML framework is truly a miserable undertaking (unless it is uses the javascript methodology, but why go down that road?!?!) and I was hoping that XAML might actually help separate the presentation.
I was also thinking that because in .NET 2.0 the concept of partial files allows the presentation to be split into a different file than the logic, this presentation part could be written in XAML. Maybe this is actually the case in how cider and sparkle work.
December 5th, 2005 at 11:21 am
Tyler, I agree with you, I hope that is the case. It seems that XAML will provide a good way to separate the presentation. It’s not necessarily what XAML/WPF provides, it’s how we choose to use it.
December 5th, 2005 at 11:27 am
yup, let’s hope that the world chooses wisely.
December 5th, 2005 at 12:22 pm
Cider
Cider is a XAML design time editor within Visual Studio.
Visual Studio will have intellisense on the XAML and will keep the XAML and cider surface in sync.
In fact, the internal XAML formatting is also preserved by Cider.
This is what a developer would use to build the code behind a XAML UI.
Video of Cider Demo
http://channel9.msdn.com/showpost.aspx?postid=129619&pvrid=152
December 5th, 2005 at 2:28 pm
Yep,
As I paraphrase Don Box here … All XAML is an XML Binding to .NET objects. No more no less.
In essence XAML is good for declaring objects and there dependencies.
Note that XAML is not only for presentation, but could be used in other paradigms in which you need to declare objects and their interdependencies. XAML makes it easier to create Visual Designers for these object declarations. For example one good candidate is workflow, hence WWF.
I am still thinking how XAML could fit into another growing Software Engineering pattern of Inversion of Control and Dependency Injection. Right now I am leaning toward that XAML was not design for IoC and DI, but could be used as a tool for it along with some othere classes in the .NET Framework.
As of now like everyone said above, you can declare your objects in XAML, but the behavior of those objects all goes “behind”.
December 6th, 2005 at 11:51 am
manung – so what youre saying is that XAML is a kind of serialization format?
December 9th, 2005 at 11:56 am
In essence, yes XAML is a kind of serialization format.
I have read an open debate on whether XAML would make a good generic XML serialization format besided being used for WPF and WWF. But I guess we will have to wait and see how XAML shapes up in the future.
May 17th, 2007 at 11:48 pm
I’ve been working with XAML for a variety of applications, and could not agree with you more about the importance of discipline when deciding on how much code should be written on the XAML side, or kept on the C# side. I’ve not run any rendering performance tests but I’d be curious to know if there is any rendering differences.
I also think the discipline of presentation to business logic is actually improved with XAML: We now we have a language that is fully capable of generating a rich user experience, and we can focus our C# efforts on your business and data abstraction layers. Then again I’ve written a handful of converters to assist the UI in consuming the business logic. I hated XAML in the beginning but now with 6 months under my belt, I’m consirering rewriting several legacy applications in WPF.
May 17th, 2007 at 11:48 pm
I’ve been working with XAML for a variety of applications, and could not agree with you more about the importance of discipline when deciding on how much code should be written on the XAML side, or kept on the C# side. I’ve not run any rendering performance tests but I’d be curious to know if there is any rendering differences.
I also think the discipline of presentation to business logic is actually improved with XAML: We now we have a language that is fully capable of generating a rich user experience, and we can focus our C# efforts on your business and data abstraction layers. Then again I’ve written a handful of converters to assist the UI in consuming the business logic. I hated XAML in the beginning but now with 6 months under my belt, I’m considering rewriting several legacy applications in WPF.