General checklist of things that have to know when converting a WPF app to MVVM

Question

Hi,

I'm taking an vanilla WPF application and converting it to use the MVVM pattern. During my evaluation of the code, I made up a list of topics that I'd need to know about before converting the application. My list looks kinda like this:

• dynamically loading xaml (although this is specific to my app)
• binding xaml to view model commands (buttons, toolbars, menu items)
• hotkeys
• binding view model commands to events (window size changes, mouse events, etc)
• handling dialogs (message boxes, file dialogs, user-designed dialogs, etc)

I already have various solutions for each item, so I'm not asking about how to do them. My actual question is: am I missing anything? What else is there that I'd need to know about?

Another way to see it is if I were making a WPF WVVM toolkit. What kind of features and functionality would it need so that developers can create MVVM apps?

Thanks!

Answer 1

You might also want to set infrastructure for some common functionality like copy/paste search buttons etc.

Answer 2

I think you've got the basic MVVM issues. What you might still need is "What do I do when my app becomes too complex for MVVM?" That happens fairly quickly--more than a couple of views, and you get a view-model explosion, or you get monolithic view models that become cumbersome and very difficult to maintain.

I'd suggest looking into the Composite WPF (Prism) framework as one solution to that problem. Prism is an architectural framework that simplifies partitioning an application into modules that are more-or-less independent of each other. Each module can have a view or two (one is probably most common), and each view can have its own view model. It does a great job of organizing communications among modules in a very loosely-coupled way. The modules load into a Shell window that can be configured however you need.

Hope that helps!

Answer 3

The first problem I faced when switching over to the MVVM was to binding events/routed events to handlers in the VM. There are no built-in or default way of doing this. I do have a helper to achieve it but its a problem you may need to consider as event handing in the code behind also defeats the MVVM pattern.