Home > WPFGlue > The Sticky Base of WPFGlue

The Sticky Base of WPFGlue


Hi,

when I first learned about WPF (short for Windows Presentation Foundation, the current UI framework for Microsoft .Net technology) I was fascinated by the idea that one could simply take a business object model, provide some forms written in XAML, connect the two through data binding, and have a new application… Unfortunately, I soon realized that there is still a lot of work to do until one reaches this stage. There are always areas where the relationship between what happens in the UI and what should go on in the business objects is not straight forward, or where the final step connecting business model and UI is missing.

The usual answer to this is ViewModels. In the Model-View-ViewModel pattern, which is the trend in WPF development at the moment, the gap between model and view is filled by the ViewModel, a specialized adapter class that knows the business model and presents it in a way that defines the functionality of the application and is tailored to fit into the data binding system of WPF. However, the examples I have studied so far did not convince me. While being very ingenious and most instructive for understanding the MVVM pattern, and doing a real good job in what they want to achieve, I found two points of criticism about these examples:

  • The ViewModels created are specialized. They may be made of reusable parts, but using them just creates another type of glue code, like forwarding the values of properties, or wrapping method calls into commands.
  • The ViewModels tend to duplicate or bypass functionality that is already provided by the WPF framework itself, like validation or navigation, because it is not easily accessible through the means the self-imposed constraints of the correctly implemented MVVM pattern leave available.

This is when I had the idea of WPFGlue. I’d like to have a library of small ViewModel building blocks which can be used from XAML files, much in the way non-visual components can be integrated into Windows Forms applications. Ideally, one could take one’s business model, and apart from that wouldn’t need to write any code except XAML in order to create an application. In order to achieve that, the components of the WPFGlue library should be small, independent of each other except where they establish their prerequisites themselves, and put no requirements on the Views on the one hand and on the business objects on the other.

So, the sticky base of WPFGlue is:

  • You shall not duplicate functionality that is already in the WPF framework.
  • You shall not mess with WPF’s correct function, like keeping objects from being freed and the like evil practices.
  • You shall not require code behind.
  • You shall not demand sub-classing controls.
  • You shall not demand interface implementations from your business objects (unless the interfaces are part of WPF itself), nor common base classes, nor any other construct that commits the developer to a strong coupling between your glue and his code.

By the way…

There are people out there who have created great frameworks for writing applications in WPF with MVVM. I think mine is (err, will be) different, but probably not better. If you are interested in the topic, check out these links:

WPF: If Heineken did MVVM Frameworks Part 1 of n by Sacha Barber on CodeProject

Caliburn by Rob Eisenberg and Co.

MVVM Foundation Classes by Josh Smith

Advertisements
Categories: WPFGlue Tags: ,
  1. No comments yet.
  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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: