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

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

The Transient Lifestyle is the safest choice of lifestyles but also one of the least efficient, because it can cause a myriad of instances to be created and garbage-collected even when a single instance would have sufficed. But, if you have doubts about the thread-safety of a component, the Transient lifestyle is safe because each consumer has its own instance of the Dependency.

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

When multiple components require the same Dependency, each is given a separate instance. The following listing shows a method resolving an ASP.NET Core MVC Controller.

private HomeController CreateHomeController()
{
    Return
        new HomeController(
            new ProductService(
                new SqlProductRepository(this.connStr),
                new AspNetUserContextAdapter(),         ❶
                new SqlUserRepository(
                    this.connStr,
                    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:

Writing Maintainable, Loosely-Coupled Code
Understanding Property Injection
Understanding Method Injection
Understanding the Composition Root
Understanding Constructor Injection
Abuse of Abstract Factories
The Service Locator Anti-Pattern
The Ambient Context Anti-Pattern
The Scoped Lifestyle
The Singleton Lifestyle