MVVM Binding Orthogonal Aspects in Views e.g. Application Settings

Question

I have an application which I am developing using WPF\Prism\MVVM. All is going well and I have some pleasing MVVM implementations. However, in some of my views I would like to be able to bind application settings e.g. when a user reloads an application, the checkbox for auto-scrolling a grid should be checked in the state it was last time the user used the application.

My view needs to bind to something that holds the "auto-scroll" setting state. I could put this on the view-model, but applications settings are orthogonal to the purpose of the view-model. The "auto-scroll" setting is controlling an aspect of the view. This setting is just an example. There will be quite a number of them and splattering my view-models with properties to represent application settings (so I can bind them) feels decidedly yucky.

One view-model per view seems to be de rigeuer...

What is best\usual practice here?

• Splatter my view-models with application settings?
• Have multiple view-models per view so settings can be represented in their own right?
• Split views so that controls can bind to an ApplicationSettingsViewModel? = too many views?
• Something else?

Edit 1

To add a little more context, I am developing a UI with a dynamic tabbed interface. Each tab will host a single widget and there are a variety of widgets. Each widget is a Prism composition of individual views. Some views are common amongst widgets e.g. a file picker view. Whilst each widget is composed of several views, conceptually a widget has a single set of user settings e.g. last file selected, auto-scroll enabled, etc. These need to be persisted and retrieved\applied when the application starts again, and the widget views are re-created.

My question is focused on the fact that conceptually a widget has a single set of user settings which is at right-angles to the fact that a widget consists of many views. Each view in the widget has it's own view-model (which works nicely and logically) but if I stick to a one view-model per view, I would have to splatter each view-model with user setting backed properties (so I can databind).

A single view-model per view doesn't sound right here if I have to splatter each view-model with user setting properties.

Answer 1

The basic problem here is using Prism to compose sub-views to make the widget - sub-views are too fine-grained.

A widget is a collection of sub-views (user controls) that work together to form a single view e.g. combining a "file picker" and a "grid list". The sub-views should be composed using straightforward Xaml to make a composite view. You still get the re-usability of the individual user controls, but the composition of the widget is fixed at design time.

Now that we have a single view: WidgetView (made of user controls), we can bind that view to a single viewmodel: WidgetViewModel. Handling the settings for the widget view is then handled by composing multiple viewmodels. Simply place a property on WidgetViewModel that exposes a WidgetSettingsViewModel. User controls bind WidgetViewModel for interacting with the underlying model, but bind to WidgetSettingsViewModel for widget settings.

In this way we can have a main viewmodel and a settings viewmodel bound to a widget.