From Dependency Injection, Principles, Practices, and Patterns by Steven van Deursen and Mark Seemann

This articles explains the Transient Lifestyle: what it is and when you might want to use it.

Take 37% off Dependency Injection, Principles, Practices, and Patterns. Just enter code fccseemann into the discount code box at checkout at

In the context of Dependency Injection, Lifetime Management is one of most prominent concepts to master. Different lifetime strategies can be applied. These strategies are formalized in the form of Lifestyles. An introduction to the concept of Lifestyles can be found here.

One of the most commonly used, and easiest to grasp Lifestyles is the Transient Lifestyle. Lifestyles are all about reusing and caching instances, but with the Transient Lifestyle, instances aren’t reused.

DEFINITION: The Transient Lifestyle involves returning a new instance every time it’s requested.

Unless the instance returned require deterministic disposal (e.g. when implementing IDisposable) there is nothing to keep track of. Conversely, when the instance does require deterministic disposal, the Composer must keep it in mind and explicitly dispose of it when asked to release the applicable object graph.

It’s worth noting that in desktop and similar applications, we tend to resolve the entire object hierarchy only once: at application startup.
This means even for Transient components, only a few instances could be created, and they may be around for a long time. In the degenerate case where there is only one consumer per Dependency, the end result of resolving a graph of pure Transient components is equivalent to resolving a graph of pure Singletons, or any mix thereof. This is because the graph is resolved only once, so the difference in behavior never kicks in.

When to use the Transient lifestyle

In many cases, you can safely exchange the Transient lifestyle for a Scoped lifestyle where access to the Dependency is also guaranteed to be serialized.

Example: Resolving multiple repositories

Listing 1 Resolving Transient AspNetUserContextAdapter instances

private HomeController CreateHomeController()
new HomeController(
new ProductService(
new SqlProductRepository(this.connStr),
new AspNetUserContextAdapter(), ❶
new SqlUserRepository(
new AspNetUserContextAdapter()))); ❶

❶ Both the ProductService and SqlUserRepository classes require an IUserContext Dependency. When the AspNetUserContextAdapter is Transient, each consumer gets its own private instance, so ProductService gets one instance and SqlUserRepository gets another.

The Transient lifestyle implies that every consumer receives a private instance of the Dependency even when multiple consumers in the same object graph have the same Dependency (as is the case in listing 1). If many consumers share the same Dependency, this approach can be inefficient; but if the implementation isn’t thread-safe, the more efficient Singleton Lifestyle is inappropriate. In such cases, the Scoped lifestyle may be a better fit.

That’s all for this article. If you want to learn more about the book, check it out on liveBook here.

You can also see other articles on common DI-related topics:

DI intro

Composition Root

Abstract Factories

Method Injection

Service Locator Anti-Pattern

Ambient Context Anti-Pattern

Constructor Injection

The Singleton Lifestyle

The Scoped Lifestyle

Originally published at

Follow Manning Publications on Medium for free content and exclusive discounts.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store