Data visualisation application for WPF and MVVM

Question

I was wondering what is the best approach for a Data visualisation application for WPF and MVVM The key points are:

1. The data is loaded, or needs just a little preparation such as pulling out particular set of data from the underlying structure.
2. The library for the data visualisation in WPF can change in the future, basically it is undecided at this point and will may change due to licensing requirements etc. So some sort or common abstraction will need to be created and custom converter, adaptors will need to be implemented.
3. Ideally MVVM pattern should be followed

My questions are:

1. If View-Model should not be concerned with View where should the implementation specific logic for the view be contained, in the code-behind? But what if I decide to change the GUI, but want to keep the same data-visualization library or vice-versa?

2. I think it is fairly clear that my common abstraction should be written in View-Model. But there are still some unclear issues such as the common idea that nothing concerned with View could be in the View-Model. But what if the whole purpose of the application is viewing of the data? I often find it confusing, as some people say that the View-Model is for logic for the View, others that it is for the application logic only. I in the past for example needed to implement DataGrid filtering in my ViewModel, due to the lack of better place, but still find it somehow not entirely clear whether it is View concern or app-logic concern, because the format of the methods is determined by what DataGrid filtering mechanism in WPF require, but the actual logic can be re-used.

Answer 1

Don't confuse "Viewing" with "View." They are not the same thing. The purpose of the view is to provide a surface area for the user to interact with. As you've already pointed out, the purpose of the application is fulfilled by the entire application, not just the view.

Here is a sound, pragmatic principle that you can follow: always put your code in the View Model (or Model), if you can. I use as little code-behind as humanly possible, for a number of reasons:

1. I don't always like the way the event model works in WPF. To write safe code-behind events in WPF you sometimes have to surround them with fences, because some events fire multiple times. You get passed bare objects in many cases, which you have to null check and cast to the proper type to do anything useful.

2. Many things that might logically seem to belong to the view don't have to be implemented in code-behind to work. For example, if you use a Command object with a button, you get a delegate in the View Model that automatically enables or disables the button using your specified rules.

3. View Model code is cleaner, clearer and more organized. Code-behind harkens back to the Winforms days when everyone wrote spaghetti-code applications.

4. View Model code is unit-testable, if you're so inclined. Testing code-behind requires a UI Testing Framework like Selenium, a much more difficult and brittle approach.