8

I have one ViewModel for enums handling (few entities in Entity Framework).

1) Philosophically, is it a good practice to use a SINGLETON PATTERN for this ViewModel, because it's widespread over all application and it's used on many places.

2) Isn't it a problem for ViewModel (and associated ObjectContext) to live for very long time?

Thank you!

Cartesius00
  • 21,471
  • 40
  • 115
  • 185

5 Answers5

11

This should probably be broken up into two separate questions, but I'll take a stab at both:

  1. No. There's no reason a ViewModel should be a Singleton. You actually WANT multiple instances (since each is going to vary) rather than a single instance that lives for the run of the application. Just because an object is widespread and is used frequently doesn't make it a good candidate for a singleton...it just means that it's a good object.

  2. ViewModels should not have a very long lifetime (another reason you don't want a singleton). In MVVM, the lifespan of a given ViewModel would be as long as the user has the window open and finishes their changes.

Justin Niessner
  • 229,755
  • 35
  • 391
  • 521
  • 2
    Hi Justin, thank you. One question... I have 3-4 windows and their content needs to be synchronized. It needs some effort to do that. I thought, if I had one ViewModel as a singleton, this pattern would automatically rebind few DataContexts... – Cartesius00 May 31 '11 at 13:57
  • A singleton would be shared not only by all "windows" but also by all users - do you really want that? – Hans Kesting May 31 '11 at 14:01
  • 1
    it is still possible to use the same instance in these four windows, you don't need a singleton for that. – L-Four May 31 '11 at 14:07
  • you need a session scoped instance. – Woot4Moo May 31 '11 at 14:18
  • it depends on your application, how is it structured? Do you use multiple modules, like in prism? Do you use injection? How do you create the views and viewmodels? Normally, you could create one instance of your viewmodel, and just set the datacontext of each window to this instance. But you could create a different viewmodel for each window (Window1ViewModel, Window2ViewModel), and each of them has a property that points to the same common instance of CommonViewModel. There are a lot of possibilities. – L-Four May 31 '11 at 14:20
2

Having a singleton ViewModel is entirely valid in specific cases. One example I have used multiple times is a SettingsViewModel. Which needs to be accessed globally by multiple systems within the app. My Settings Model on creation loads up settings from a file, the ViewModel allows me to bind to modify those settings. The singleton allows me to globally access those settings where I need instead of passing them around as parameters.

Entirely valid, in this case.

Asheh
  • 1,427
  • 13
  • 22
  • 2
    IMO, in your description, it sounds like the Model is the singleton, not the ViewModel. Normally the view model is the glue between a view instance and the Model instance. A view model would not normally store state scoped outside the View it is attached to, it should only control functionality. – Allan Jun 21 '16 at 05:31
1

1) don't do it. see MVVM ViewModels Singleton 2) I don't think it's a good idea to have a viewmodel coupled to an object context. It should be just a viewmodel, providing data to a view; but not tightly coupled to any data persistance technology. Instead, inject services that take care of this, so you can mock them.

Community
  • 1
  • 1
L-Four
  • 11,965
  • 8
  • 52
  • 103
0

The objects only live on the stack as long as the garbage collectors deems them to be necessary. Philosophically no it is not a good idea to use Singleton as it breaks encapsulation. See article: Singleton antipattern

Woot4Moo
  • 22,887
  • 13
  • 86
  • 143
  • a thousand apologies, heap. http://stackoverflow.com/questions/2129044/java-heap-terminology-young-old-and-permanent-generations – Woot4Moo May 31 '11 at 14:06
0

As Justin mentioned, it seems unlikely you'll need your ViewModels to follow the Singleton Pattern. However, as you mentioned, View Models are used throughout the system. Consider pulling common functionality into base classes (if you like inheritance) and/or pull reusable components into objects to take advantage of composition.

An easy way to start this is all the lines of Josh Smith's ViewModelBase and a typical ViewModel's usage of INotifyPropertyChanged.

Give that code a look here: http://mvvmfoundation.codeplex.com/

Jimmy Lyke
  • 330
  • 1
  • 9