OK - I have had a “pet project” using WPF for a few months now. We will be “starting for real” in a few months “at the office” it seems. I will have to have built ~2-3 pet projects over the next 2 months to be happy.

I wil say - the web is great. There is nothing better than working with WPF to understand what is happening. I think a lot of people have mixed thoughts about WPF, but for the past several years now, I have been trying to move to a more declarative style of programming in general. I have typically tried to make it so that i could wire together a bunch of stuff for a scenario using Spring.net - or hand rolled domain specific XML. This is in the spirit of XAML… They have objects that have lots of properties - then you declare the behavior as you need in XAML (or you let a tool do it more likely).

There are several key concepts that developers need to get a handle on. As soon as you get past the “initial playing around” with WPF and try to make a real, clean, well written, maintainable piece of software - you will need to really understand WPF and how it works. So, on to…

Understanding Dependency Properties.

Single most helpful statement in starting to understand WPF Dependency Properties: 

Dependency properties and the WPF property system extend property functionality by providing a type that backs a property, as an alternative implementation to the standard pattern of backing the property with a private field.

From MSDN’s Dependency Properties Overview

Another useful statement can be foun in Windows® Presentation Foundation Unleashed

A dependency property depends on multiple providers for determining its value at any point in time. These providers could be an animation continuously changing its value, a parent element whose property value trickles down to its children, and so on.

Dependency properties are understood by XAML only. It is all “normal .net (C#)” but it is only meaningul within the context of XAML. Dependency properties give you a type as a property, so you get a level of indirection that buys you:

1. Property change notification
2. Support for different providers (various ways to change the value of the … uhm value)
3. Property inheritance (think of it as propagation of a value to child controls)

The implementation of dependency props - it looks odd, but it makes sense if you think of it something like:

My class is implementing its property in a way that it can be hooked into WPF intimately.

(this is verbatim from the WPF Unleashed book)

The static DependencyProperty on top - is point of ref that wires up the connection in the static constructor. It is used to attach the change notification method, the metadata info, the type info, etc. (All this static business is a bit disconcerting for me as a TDD anti-singleton type.) Note the “normal” .net property IsDefault - looks like a normal property. The rest of that stuff is the implementation of the property - in such a way as WPF is “wired into it”. Now you get the Property change notification, property propagation, hook points for value changing, etc. Now your class is all bound to WPF… This is another item that provides food for mental thought…

That last paragraph has some uglies in it…

• #1 Static singleton stuff (you are bound to global stuff from your environment -ugh).
• #2 more of the same, your implementation is explicitly bound to its runtime environment.

I am open to new things That said - those things make me a bit uncomfortable. I believe in a style of programming that allows you to be declarative, and to wire together components. I believe you can use labels, identifiers, strings, and all that stuff to be the glue to stick stuff together. This gets you a bit away from a very strong compile time safety, yet you get the benefits of a much more dynamic and flexible style of programming. I think the ideas of XAML works right into my general modus operandi. I think it is important to be careful to make sure we can still write testable code!

As systems get bigger and bigger and more complex - more risk is at play. Especially on Wall St - lots of $ can be lost if you are buggy. Testability is a cornerstone to sustainability. For me - the key takeaway is to ONLY bind up your presentation tier into the WPF specific stuff. Just like today - there are lots of apps where WAY too much is way up in the view code.  I still want a POCO (plain old CLR object) feel when programming!

Anyhow - that is it for me - 2 year old is now awake and wants to play!

-Chris

Comment on this post below

You must be logged in to post a comment.

You can leave a response, or trackback from your own site.