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.
4 comments:
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 :).
thanks Rutix, that's an intersting technique. Recently I've been experimenting with notifypropertyweaver which is another way to get rid of magic strings.
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.
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!
Post a Comment