Building an MVVM-Based Architecture That Works for Windows Store Apps

Sign in to queue


This session shows how you can set up the architecture for your Windows Store App in a way that works well, both from a development point of view and from a designer point of view. Adopting the MVVM pattern is a step in the right direction, but unforutnately it isn't enough. Getting the most out of the tools requires the architecture to play nice, and working without the support of the tools is hard, so getting the architecture right is paramount.

For more information, check out this course on Microsoft Virtual Academy:


Windows, Breakout



Session Type:





Room 276



Download this episode

For more information, check out this course on Microsoft Virtual Academy:

The Discussion

  • User profile image

    May I know if it would cover the Blend tool? Thanks.

  • User profile image

    Hi Eric!
    No, this talk will unfortunately not cover Blend at all. This is all code and architecture...

  • User profile image

    I enjoyed the session, but I must disagree with your assertion that async/await is more complex than callbacks.

    First, there is an exception in the Task: Task.Exception. Conceptually, the Task<T> type can represent either success or error; it has both a Result and Exception property, which are roughly analogous to the two parameters for your callback.

    Secondly, an implementation of IProgress<T> is already provided (Progress<T>), which you can instantiate with a delegate as such: "new Progress<int>(value => { ... })". In an MVVM app there's no need to create your own.

    Those are the only real drawbacks to async/await that you mentioned. However, async/await also has several advantages over callbacks:

    1. You mentioned one drawback to chains of asynchronous operations: the lambda nesting can get unwieldy. Await avoids this completely.
    2. Another thing you mentioned is that it can be easy to accidentally ignore exceptions in callback code. The Task<T> type prevents this by encapsulating the result.
    3. Await and Progress<T> both use SynchronizationContext automatically in an intelligent way. This makes any kind of thread marshaling or dispatcher service completely unnecessary, cleaning up service/VM code. 
    4. Error handling is easier. With callbacks, exceptions must be propagated explicitly. Await will naturally propagate them, keeping the original exception type and call stack even if the thread context changed. This is quite difficult to do yourself with portable code.
    5. Await makes more complex asynchronous operations much easier to deal with. E.g., retrying on error, or doing multiple operations at once. With callbacks, these kinds of operations quickly become difficult and commonly require actual callback methods instead of lambdas. With async/await (plus TaskEx.WhenAll / TaskEx.WhenAny), they're quite easy to do.

Add Your 2 Cents