I don't like "never." What would you use in a client-side Blazor application for keeping up with app state if not a singleton service? Which then, by the way, still has to be injected.
I'm actually super happy you brought this up. You're referring to services.AddSingleton<T>, yes? I argue that this method is misnamed. I think it should be renamed to AddShared or something like that. When you inject an object in this manner, it's merely instructing the framework to reuse a single instance. It doesn't suddenly bestow all the qualities of a singleton upon that class. I can still voluntarily create another instance somewhere. The constructor is not locked down per the singleton design pattern.
(Oh you said client-side Blazor. I've not made one of those. Regardless, you don't need a true singleton.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't like "never." What would you use in a client-side Blazor application for keeping up with app state if not a singleton service? Which then, by the way, still has to be injected.
I'm actually super happy you brought this up. You're referring to
services.AddSingleton<T>, yes? I argue that this method is misnamed. I think it should be renamed toAddSharedor something like that. When you inject an object in this manner, it's merely instructing the framework to reuse a single instance. It doesn't suddenly bestow all the qualities of a singleton upon that class. I can still voluntarily create another instance somewhere. The constructor is not locked down per the singleton design pattern.(Oh you said client-side Blazor. I've not made one of those. Regardless, you don't need a true singleton.)