WPF FAQ

I am working on my new WPF FAQ which will be available on my site shortly.

Although I know there are many out there, in my new role as a WPF developer I will use it as a target for noting down all those things I find useful during my learning curve.

Hopefully it will benefit others too.

WPF same-old sameold.

I am currently trying to immerse myself in WPF from a practical and useful standpoint. My usage of this new system has been fairly light and fluffy up until now, I have been puzzled by some of the new concepts, realised that the framework has taken a totally different direction recently and been have wowed by the promise of "A New Hope" or, if you'll forgive me, a paradigm shift.

However, when I began seriously looking into what can be done on a practical level with XAML and how data and XML can be used to build pretty cool applications I find myself coming to the conclusion that its all really business as usual in the world of the programmer.

When you look at XAML and the various cool looking demo applications that are out there you will see in fact that XAML is only as good as the components you can use on your pages and windows. The supply of these components requires programming skills that are firmly based in traditional methods and despite the fact that XAML provides a declarative way of creating an interesting look and feel, when one begins writing a custom control, one is still forced to roll up the sleeves and get to work with good old C# or Visual Basic in the codebehind file.

Certainly XAML is a great way of defining a user interface and incorporating the design elements we need now but the need for strong architectural skills and a supply of high quality controls for all these markup-jockeys to consume is still of paramount importance.

2.NET|!2.NET

Arthur C. Clarke once said "Any sufficiently advanced technology is indistinguishable from magic"

A few times recently, I've been in a situation where I just wanted to hold my head in my hands and groan "Noooo not again!! make it stop!!". Why? Well, because even after seven years of .NET people still don't get the idea of what advantages there are in fully embracing the framework's philosophies to create really great applications or components.

Imagine dumping a medieval man into the middle of London. Aside from the obvious initial shock, he'd become used to the idea that cars travelled about without horses attached to them, he could even learn to drive a car. He would become used to the idea of lighting without flames and he'd eventually become a consumer of fish and chips or MacDonald's burgers without necessarily understanding how it all happened or what made it all tick. After his short period of adjustment that went from screaming fits and soiling himself with fear, we would eventually get someone who can function just fine in the environment. Whether he could design a car or grasp the concepts of electricity would be however, a different subject entirely.

This is the sort of thing that happens when someone who is "expert" in 1990's technology gets hold of the concepts of third millennium .NET framework. They become a perfectly adequate programmer, able to apply their concepts of programming to C# or VB.NET and as long as their efforts are contained within a single sealed up application all is well and you can't tell the difference from the outside.

What happens however when that person, however innately intelligent they may be, applies 1990's ideas to .NET architectures and has the responsibility for creating, say, a huge data management framework of industrial proportions? You guessed it. A complete and total disaster that does nothing but make people groan with disbelief.

For me, the best aspects of .NET architecture are the ones that don't fall readily to mind, even if you're a world-renowned C++ guru and have 20 years of experience in your field. For example, the idea that your objects may take part in a design time environment. This was not even a possibility in the old world of C++ but now you should seriously consider whether your objects should at least carry the attributes such as Browsable, Description, Category etc. Furthermore, you should ensure that your object has a type-conversion strategy, should implement ToString correctly, provides a design-time editor, possibly a graphic editor, certainly a smart-tag, some designer verbs and so-on.

When designing an architecture today, we also need to look to current trends in data-binding. It used to be that tying an object to a GUI was a laborious process that required either brute-force, the preferred C++ method, or implementation of some pattern such as Model View Controller (MVC). Any remotely skilled Windows Forms engineer will immediately use data binding which neatly sidesteps these issues. However, the objects in question need to either provide changed events for properties or implement INotifyPropertyChanged. So, I hear everyone reading this beginning to say "Well, if the object is some deep part of a framework and not exposed to the GUI, why bother?" The answer here of course is that data-binding is no longer a GUI only issue. .NET 3.0 and 3.5 already has data binding that can take place between any two properties so that otherwise invisible objects can be bound. This is not only interesting for WPF maniacs but for anyone who has an object that receives input from another.

Finally, meta data and reflection coupled with new type description systems are so powerful that it adds vast new aspects to object orientation that are so outside the realms of the classic Encapsulation, Inheritance, Polymorphism triad that classes have ceased to become immutable definitions and have entered the realms of chimeric virtual objects that appear to be one thing when they are, in reality, something totally different.

If you're an architect and expecting to create a framework for your flagship product by all means pick .NET. Just don't go blundering about like a medieval peasant when you could be using magic instead.