Update dependency-injection-guidelines.md to suggest avoid singleton for stateless service #47991
Conversation
…for stateless service Over years I have seen multiple companies use singleton as default IoC scope. So I want to update guide line to make clear what is the cost, suggest at least avoid singleton for stateless service
PoliCheck Scan ReportThe following report lists PoliCheck issues in PR files. Before you merge the PR, you must fix all severity-1 issues. Other issues are also a high priority. The AI Review Details column lists suggestions for either removing or replacing the terms. If you find a false positive result, mention it in a PR comment and include this text: #policheck-false-positive. This feedback helps reduce false positives in future scans. ✅ No issues foundMore information about PoliCheckInformation: PoliCheck | Severity Guidance | Term |
dotnet-policy-service
bot
added
dotnet-fundamentals/svc
community-contribution
There was a problem hiding this comment.
Pull Request Overview
This PR updates the dependency injection guidelines to provide more comprehensive guidance on singleton service lifetimes, specifically advising against using singleton for stateless services. The update addresses common misconceptions where singleton is used as a default IoC scope by explaining the costs and drawbacks.
- Clarifies when to use factory pattern for IDisposable instances
- Adds detailed guidance on singleton usage with emphasis on avoiding singleton for stateless services
- Lists specific considerations and drawbacks of singleton lifetime including thread safety, coupling, testing challenges, and performance implications
Co-authored-by: Copilot <[email protected]>
|
IMO this updated guideline seems to be giving a dangerously blanket advice to 6-8 million .net developers, nearly-encouraging them to swipe state management problems under the carpet of transient lifetime, instead of striving for clean stateless design and zero-allocations as seems to be the default guideline in the Java/Spring community. I understand the pragmatism of giving .net developers what you probably see as a safe "lowest common denominator" approach that'd keep them out of trouble, and in the legacy codebases with no design governance making everything transient by default may indeed be the only viable survival strategy, but framing it as THE best practice for all codebases, makes it hard to impossible to advocate for clean stateless-by-default design now that "Microsoft said it's a bad idea". |
3 participants
Over years I have seen multiple companies use singleton as default IoC scope.
So I want to update guide line to make clear what is the cost, suggest at least avoid singleton for stateless service
Summary
I add a list to list what are the drawbacks of singleton, emphasis when and esp. when not to use Singleton IoC scope.
Internal previews