Due to popular demand, I have finally got round to recording part three of my modular WPF application screencast series. Rather than jumping directly to a fully featured solution, I wanted to show how we might evolve an architecture step by step, and without being afraid to make some wrong choices that we will need to refactor later.

  • Part 1 covered setting up the framework to use MEF
  • Part 2 covered adding MVVM to make it unit testable

In this episode I walk through adding a new feature, the ability to cancel switching between modules, which turns out to be a bit more tricky than we might have anticipated, and ends up with us creating a templated list of buttons to replace our original ListBox. (n.b. an even better choice might have been to use a tab control, but I didn’t think of that when I created this tutorial, so maybe that can be another refactoring for a future episode).

Also, loads of people are asking for the code, so I have made the Mercurial repository publicly available. In the video, the reason you don’t see me coding, is because I am just switching between revisions of my repository (and it also keeps the video much more succinct). I’ve bought a new headset too, so the voice quality ought to be better than before (although I’ll probably reduce the level slightly for next time). I also tried capturing at 1280x720, so there is a bit more screen real estate. Let me know if this is better or worse.

Want to learn about how to create modern looking WPF applications with MahApps.Metro? Be sure to check out my Pluralsight course Creating Modern WPF Applications with MahApps.Metro.
Vote on HN


Comment by Rutix

Thanks m8! Was waiting for part 3 ^_^.
One improvement I can say is that you have magic string when using the RaisePropertyChanged .

You use something like this:

public class PropertyOf
public static string Resolve(Expression> expression )
Expression candidate = null;

if (expression.Body is UnaryExpression)
candidate = (expression.Body as UnaryExpression).Operand;

if (expression.Body is MemberExpression)
candidate = expression.Body;

return (candidate as MemberExpression).Member.Name;

And then call it like this:

RaisePropertyChanged(PropertyOf.Resolve(x => x.UserInterface));

That would remove the magic strings :).

Comment by Rutix

Oh that notifypropertyweaver looks interesting. I will look into that too, since the problem with my technique is that you lose some performance since it needs to do the expression stuff while the string one is just passing the string.

Comment by Sebisebo

I've just finished watching the 3 parts and I absolutely loved it. By far the most comprehensive and pragmatic MVVM tutorial I've seen so far...Great work!

comments powered by Disqus