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.