Note: this article is published on 07/09/2024.

These will be a series of articles about Design Patterns. We start from MVC Pattern:

A - Introduction

.NET supports the dependency injection (DI) software design pattern, which is a technique for achieving Inversion of Control (IoC) between classes and their dependencies.The previous article introduced the Dependency Inversion Principle, and the Dependency Injection in concept. This article will discuss more about the implementation of Dependency Injection. The content of this article:

B - Roles in Dependency Injection

Dependency injection involves four roles: services, clients, interfaces and injectors.

Services and clients

A service is any class which contains useful functionality. In turn, a client is any class which uses services. The services that a client requires are the client's dependencies.

Any object can be a service or a client; the names relate only to the role the objects play in an injection. The same object may even be both a client (it uses injected services) and a service (it is injected into other objects). Upon injection, the service is made part of the client's state, available for use.

Interfaces

Clients should not know how their dependencies are implemented, only their names and API. A service which retrieves emails, for instance, may use the IMAP or POP3 protocols behind the scenes, but this detail is likely irrelevant to calling code that merely wants an email retrieved. By ignoring implementation details, clients do not need to change when their dependencies do.

Injectors

The injector, sometimes also called an assembler, container, provider or factory, introduces services to the client.

The role of injectors is to construct and connect complex object graphs, where objects may be both clients and services. The injector itself may be many objects working together, but must not be the client, as this would create a circular dependency.

Because dependency injection separates how objects are constructed from how they are used, it often diminishes the importance of the new keyword found in most object-oriented languages. Because the framework handles creating services, the programmer tends to only directly construct value objects which represents entities in the program's domain (such as an Employee object in a business app or an Order object in a shopping app)

C - Advantages and disadvantages for Dependency Injection

The Advantages and disadvantages for Dependency Injection:

Advantages

Disadvantages

Critics of dependency injection argue that it:

D - Types of Dependency Injection

There are three main ways in which a client can receive injected services:

E - Service Lifetimes Managed by DI Container

In the realm of .NET Core development, managing dependencies efficiently is crucial for building scalable and maintainable applications. The .NET Core framework provides a powerful built-in dependency injection (DI) container to handle the instantiation and resolution of dependencies. Understanding service lifetimes is essential for leveraging the full potential of DI in .NET Core applications. In this article, we'll explore the concept of service lifetimes and provide console example to illustrate their usage. This is the content of this article.

Service lifetimes determine how instances of services are created and managed within the DI container. In .NET Core, there are three main service lifetimes.

  1. Transient: Transient services are instantiated each time they are requested. This means that a new instance is created for every injection or retrieval request. Transient services are ideal for lightweight components that do not maintain state between method calls.
  2. Scoped: Scoped services are created once per request within the scope of a specific operation or component. The same instance is reused throughout the request. Scoped services are commonly used in web applications to manage resources that need to be shared within a single request.
  3. Singleton: Singleton services are instantiated only once per application and shared across all requests and components. Once created, the same instance is reused throughout the application's lifetime. Singleton services are suitable for stateful components that maintain a shared state or hold expensive resources.

References: