Lifetimes
Choose How Long an Instance Should Live
Lifetimes are part of the application design. A service that has no mutable runtime state can be shared. Request-like state needs isolation. Fresh builder-style objects should be transient. Pick the right lifetime and the container handles the rest.
Quick Reference
- Singleton
- LoadAs.Singleton
- Default for stateless services, repositories, readers, formatters, and orchestrators. One instance shared across the entire container tree.
- Scoped
- LoadAs.Scoped
- Use for request, page, user, conversation, or test-case state that must not leak across scopes. Fresh instance per child container.
- Transient
- LoadAs.Transient
- Use rarely, when every resolution must return a fresh mutable object. New instance on every resolution.
Documentation
Singleton
Share one instance across the application. The default lifetime for most NoEgo services.
Scoped
Isolate state per request or page using container.extend(). Shared singletons, isolated scoped state.
Transient
Create a fresh instance every time. Rarely needed — prefer Singleton + method parameters instead.
Core Rules
- Singleton is the safe default for stateless services — use it unless you have a reason not to.
- Use Scoped for state that changes per request, page, or conversation.
- Use Transient sparingly — builders and accumulators are the typical use case.
- Pass changing data as method parameters instead of holding it in instance state when possible.
- Create child scopes with container.extend() for request isolation and test fakes.