2

The WPF Combobox needs to bind a collection to it's ItemsSource and something to bind the selected item or value to. Until now, I've included both the collection and the selected value properties that I'm binding on the ViewModel that is responsible to the given view hosting the Combobox.

Lately, I've been reviewing how I've implemented MVVM in my past projects, and I've noticed some things that I'm not happy with. One of them is that if multiple views need the same ComboBox, then each associated ViewModel had it's own copy of the collection. I was thinking that it would be better to expose the collection at an application level, and just provide a property for binding the selected value in each pertinent ViewModel.

The way I see it working is to have a singleton ViewModel that is kept alive for the entire lifetime of the application. This ViewModel would have all of the standard collections that aren't specific to individual ViewModels.

As I'm using Entity Framework, it would have it's own context, so the Selected Item properties would have to bind to the foreign key of the entity instead of the navigation property since the various ViewModels wouldn't share contexts.

From there, I could encapsulate the various collections within a ResourceDictionary as a set of StaticResources, and then use those to bind to the ItemsSource of various ComboBoxes throughout the application.

My question is this; Is this crazy/stupid? I taught myself WPF/MVVM from a number of sources, and I'm never sure if I'm straying from generally accepted practices.

My thoughts behind all of this was that having the one source would allow multiple viewmodels to have a synced set of drop down collections. If I change the collection in one spot, the rest would show the same changes, as they all are bound to one source. Before, I needed a mediator to maintain consistency between ViewModels.

Additionally, it would provide a simple, centralized and bindable singleton class to store application scoped variables, such as the currently logged in user.

So, is there an obvious flaw to this that I might be missing? In the past, I implemented my MVVM pattern without any external validation. It works, with only a few growing pains... but I'm sure that it could have benefited greatly from some peer review.

Improve this question
2
  • 2
    Just because you want a shared combobox source (might be a good idea) doesn't mean you have to make it a singleton (certainly a bad idea).
    – Wilbert
    Jul 23, 2014 at 13:56
  • 1
    It would be quite easy, for instance, for all the viewmodels to hold the same instance of whatever contains the items without it being a singleton. I've used MEF to do this more easily, but you could also manually pass it into the construcors.
    – Magus
    Jul 23, 2014 at 14:43

2 Answers 2

Reset to default
1

there should be no problem in binding ItemSource of multiple comboboxes to a static list of options, as long as the SelectedValue is bound to each model instance. take for example a dropdown of US States, all instances should be sourced from one application-wide collection.

Improve this answer
0

A ViewModel is a model intended for a specific view. The idea of having a "common" ViewModel that is shared across views is counter to this idea.

If you discover that many of your ViewModels have elements in common, I suggest that you implement good old fashion inheritance. You may have a BaseViewModel that has members for retrieving and populating combo boxes of various kinds, and each of the ViewModels that need those members can simply inherit from BaseViewModel. You may also end up with more than one inheritance branch; for example, you may have a CustomerViewModel, which contains combo boxes needed by a customer, and a separate AdminViewModel, which contains combo boxes needed by admins, e.g. a combobox for "User role."

One thing in your post that troubles me-- you write of each ViewModel havings its own copy of a collection. I am not sure that is accurate. A ViewModel is created when the request for the View arrives, and is destroyed after the request has been processed and a response has been returned. The idea that there are all these different ViewModels that are persisting a collection at the same time does not seem accurate when you consider this context.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.