1

Register in startup as Singleton, Scoped or Transient, Singleton means only a single instance will be created ever.

Say we have a UserInfo 

services.AddSingleton<IUserInfo , UserInfo >();

and this UserInfo is populated somewhere else, might be middleware, or a service like factory with phoneNumber. email so on...

If we use Singleton with User 'Fred' Then user 'Jack' comes along does user Jack get Freds instance complete with Data until it's overwritten with Jacks Data ?

So that would mean we use scoped as it's an instance per scope, a scope is created with every request and if you need to do something with userInfo more that once per request we would use Transient ?

Transient being a new instance every time

Struggling to find a way to test these scenarios any ideas appreciated, Thanks.

fuzzybear
  • 2,325
  • 3
  • 23
  • 45
  • Question reminds me this - https://stackoverflow.com/questions/38138100/what-is-the-difference-between-services-addtransient-service-addscope-and-servi – Alexander S. Mar 15 '18 at 16:01
  • @AlexanderS. thanks I have seen it and it's probably me it's not clear enough that's why I choose to use a real world user scenario, I could test it more, but would never be sure as it's very hard to trap 2 users coming in at very close intervals! I Think that means singleton could end up being overwritten, so it would probably be scoped ? – fuzzybear Mar 15 '18 at 16:05
  • See [the section titled Singleton VS Transient Example here](https://stackoverflow.com/a/49157202). The lifetime indicates when the class instance will go out of scope. Scoped lifetime is similar to singleton, except that the instance is stored in `HttpContext.Items` instead of a class-level container variable. – NightOwl888 Mar 15 '18 at 16:47

1 Answers1

4

Singleton means new instance per application lifecycle. Scoped means new instance per request. Transient means new instance every time it's injected.

The problem you're likely having is that, in development, there's a fair amount of overlap between these things. If you're injecting it only one time, after you just made a code change, there's effectively no difference in the three scopes as all will result in a single new instance being created. This is because:

  1. With singleton scope, the site was just restarted due to the code change. As a result, it's a brand new process which needs a new instance.
  2. With request scope, you're making a request, so you're always going to get a new instance
  3. With transient scope, you only ever inject it once, so only one instance is being created.

However, in the "real world" the differences are more pronounced. Your app may be up for days, weeks, months, without being restarted. A singleton-scoped instance will survive this whole time. Transient is pretty much bound to the scope of the object it's being injected into. If you inject something with transient-scope into something with singleton-scope, then the transient-scoped instance is effectively singleton-scoped, as long as it doesn't get injected into anything else. Finally, request scope is request scope. New instance, every request, every time.

It's important to note that request-scoped instances don't tend to play nice with other types of scoped instances. For example, the database context is usually request-scoped. As a result, you cannot inject it into something that is singleton-scoped. You'll actually get an exception if you try. However, you can go the other way: inject a singleton into a request-scoped instance.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444