Is there a better way than using static classes or singletons for MVVM?

Question

I've found that in a lot of cases, it seems (at least superficially) to make sense to use Singletons or Static classes for models in my WPF-MVVM applications. Mostly, this is because most of my models need to be accessed throughout the application. Making my models static makes for a simple way of satisfying this requirement.

And yet, I'm conflicted because everyone on the planet seems to hate singletons. So I'm wondering I there isn't a better way, or if I'm doing something obviously wrong?

Making "MODELS" Static?? No, not really. Not even a little bit. That's even worse than [parsing HTML with RegEx](http://stackoverflow.com/a/1732454/643085) — Federico Berasategui, Jun 04 '13 at 19:01
If using DI, instead of making it static, register it in the container with the ContainerControlledLifetimeManager. With static, you have more of a problem with thread safety. — Chuck Dee, Jun 04 '13 at 19:07

score 5 · Accepted Answer · answered Jun 04 '13 at 19:03

There are a couple of issues with Singletons. I'll outline them below, and then propose some alternative solutions. I am not a "Never use a singleton, or you're a crap coder" kind of guy as I believe they do have their uses. But those uses are rare.

Thread safety. If you have a global-static Singleton, then it has to be thread-safe because anything can access it at any time. This is additional overhead.
Unit Testing is more difficult with Singletons.
It's a cheap replacement for global variables (I mean, that's what a singleton is at the end of the day, although it may have methods and other fancy things).

See, it's not that Singleton's are "horrid abominations" per-se, but that it's the first design pattern many new programmers get to deal with and its' convenience obfuscates its' pitfalls (Just stick some gears on it and call it steam-punk).

In your case, you're referring to Models and these are always "instances" as they naturally reflect the data. Perhaps you are worried about the cost of obtaining these instances. Believe me, they should be negligible (down to data-access design, obviously).

So, alternatives? Pass the Model to the places that require it. This makes unit testing easier, and allows you to swap out the fundamentals of that model in a heart-beat. This also means you might want to have a look at interfaces - these denote a contract. You can then create concrete objects that implement these interfaces and voila - you're code is easily unit-testable, and modifiable.

In the singleton world, a single change to that singleton could fundamentally break everything in the code-base. Not a good thing.

Nice. I would even say: don't ever use singleton unless you don't have another choice. — L-Four, Jun 04 '13 at 19:51

score 2 · Answer 2 · answered Jun 04 '13 at 19:02

2

I think the accepted solution to this problem is to use dependency injection. With dependency injection, you can define your models as regular, non-static classes and then have an inversion of control container "inject" an instance of your model when you want it.

There is a nice tutorial at wpftutorial.net that shows how to do dependency injection in WPF: http://wpftutorial.net/ReferenceArchitecture.html

answered Jun 04 '13 at 19:02

Erik Schierboom

16,301
10
64
81

Interesting. I started learning DI a couple weeks back. Looks like I'll be picking that back up. Thanks. – sircodesalot Jun 04 '13 at 19:04

Emond · Answer 3 · 2013-06-04T19:10:30.987

The only static class I use is a MessageBroker because I need the same instance all through the application.

But even then it is very possible to use Unity (or another Dependency Injection/Container) to manage instances of classes that you only need one of.

This allows you to inject different versions when needed (e.g. during unit tests)

BTW: static is not the same as singleton. But I am not getting into that here. Just search stackoverflow for more fun questions on that :)

Is there a better way than using static classes or singletons for MVVM?

3 Answers3