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

Question

I found that in many cases it seems (at least superficially) to make sense to use singletones or static classes for models in my WPF-MVVM applications. This is mainly due to the fact that most of my models need to be accessed throughout the application. Creating my static models makes it easy to meet this requirement.

And yet, I contradicted, because everyone on the planet seemed to hate singles. So I wonder if there is a better way, or am I doing something obviously wrong?

Answer 1

There are a couple of issues with Singletons. I will describe them below and then suggest alternative solutions. I'm not “Never use a singleton, or you're just a shitty coder,” I suppose they have their own capabilities. But this use is rare.

• Thread safety. If you have a globally static Singleton, then it should be thread safe, because everyone can access it at any time. This is an additional overhead.

• Unit testing is more complicated with Singletons.

• This is a cheap replacement for global variables (I mean, one single at the end of the day, although it can have methods and other fancy things).

You see, this is not that Singleton is “terrible abominations”, but it is the first design that many new programmers encounter, and its “convenience” confuses its “pitfalls” (just put on some mechanisms on it and name it steam punk).

In your case, you mean models, and they are always “instances,” since they naturally reflect data. You may be worried about the cost of getting these cases. Believe me, they should be insignificant (up to the design of access to data, obviously).

So alternatives? Pass the model to places that require it. This simplifies unit testing and allows you to change the fundamentals of this model in the heart. It also means that you can take a look at the interfaces - this is a contract. Then you can create specific objects that implement these interfaces, and voila - you can easily test and modify the code.

In the singleton world, a single change to this singleton can fundamentally break everything in the code base. Not good.

Answer 2

I think the accepted solution to this problem is to use dependency injection. By using dependency injection, you can define your models as regular, non-static classes, and then invert the control container to “insert” an instance of your model whenever you want.

Wpftutorial.net has a good tutorial that shows how to do dependency injection in WPF: http://wpftutorial.net/ReferenceArchitecture.html

Answer 3

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

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

This allows you to enter different versions if necessary (for example, during unit tests)

BTW: static is not the same as singleton. But I do not understand what is here. Just search stackoverflow for more interesting questions about this.