3

This is really confusing for me. Nothing is stopping us from creating a class with instance fields and instance methods, versus creating a class with static fields and static methods. Both can be registered as a singleton.

Is there a preferred approach to this problem, and why?

EDIT: I'm not asking about creating a class using the singleton pattern. I'm asking about singleton dependency injecting a class versus injecting the same class but with static defined members/fields/methods/properties.

Guillaume S.
  • 1,515
  • 1
  • 8
  • 21
SpiritBob
  • 2,355
  • 3
  • 24
  • 62
  • Does this answer your question? [Difference between static class and singleton pattern?](https://stackoverflow.com/questions/519520/difference-between-static-class-and-singleton-pattern) – Johnathan Barclay Feb 19 '20 at 14:54
  • Would you even need DI for the static class? – Joe H Feb 19 '20 at 15:10
  • @JoeH if you introduce a constructor with other services - yeah you do. Otherwise concrete implementation would need to use concrete classes. – SpiritBob Feb 19 '20 at 15:15

3 Answers3

12

You need to understand the different lifetimes for DI and your needs, in order to choose the proper life span.

  • Transient services are created each time the service is requested (So if in 1 request, a service is used 2 times, it will be created 2 times).
  • Scoped services are created per web request (So if in 1 request, a service is used 2 times, it will be created only once).
  • Singleton is an instance that will last the entire lifetime of the application (All requests will share this one instance).

If in doubt, make it transient.

EDIT

I guess its worth to mention that if you create a services as Transient and they have static properties which you constantly change, then this will affect every other created instance, since static affects the type itself, rather than an instance.

Rafa
  • 443
  • 5
  • 14
  • 1
    I'm aware of the lifetimes. I'm asking about a completely different thing. What is the difference between a object injected as a singleton that has no static fields/properties/etc, versus injecting the same object as a singleton, but having static fields/properties/etc. – SpiritBob Feb 19 '20 at 17:33
2

I'm asking about [...] injecting the same class but with static defined members/fields/methods/properties

That is possible but useless. If a controller requires such a singleton object, then you still have no instance method to call on this object. Your controller have to call static methods on the class.

[...] creating a class with instance fields and instance methods

That is a better way to do because it will allow you to mock the object for unit testing.

If you want concrete example, I've coded a class with instance methods to store data about users, which is registered as a singleton object, and used in controller.

Hope it makes things clearer for you.

Guillaume S.
  • 1,515
  • 1
  • 8
  • 21
  • Is it okay if it uses private static read-only fields for its purposes then? Or should they be made non-static? – SpiritBob Feb 20 '20 at 14:31
  • @SpiritBob Can you be more specific? Do you mean: is it possible that the singleton object uses static fields of its own class? Yes it's possible. It's better to make them private so that the external classes can not reference those static fields. The external classes should only use the singleton object. The most important is to make sure your singleton object is thread-safe because an ASP.NET Core application does handle *concurrent* web requests. That's why I use a lock in my example when to read/write a shared ressource, eg the list that store the user list – Guillaume S. Feb 20 '20 at 16:35
0

static class fields can be modified by other instances of the same class. by registering a class as singleton with static fields you will be relying on the fact that never in any other parts of the app any other instances of the same class will be created.

i realize that you will focus on obtaining an instance from DI - however, if anywhere in the app there is a point anohter instance of the class is instantiated directly and not via DI - the static property will be exposed to potential change of it state (value).

working with singleton instance properties/fields will ensure you only work with the properties/fields controlled by the instance you get from DI.

Yan D
  • 136
  • 2
  • 11