0% found this document useful (0 votes)
38 views54 pages

Chapter 03 - Dependency Injection in

The document provides an overview of Dependency Injection (DI) in .NET, including the SOLID principles, Inversion of Control (IoC), and various DI patterns such as Constructor, Property, and Method Injection. It discusses the benefits and challenges of DI, as well as the built-in DI container in .NET Core that simplifies dependency management. Additionally, it covers service lifetimes and key classes related to DI in .NET applications.

Uploaded by

dieptcnnde170171
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
38 views54 pages

Chapter 03 - Dependency Injection in

The document provides an overview of Dependency Injection (DI) in .NET, including the SOLID principles, Inversion of Control (IoC), and various DI patterns such as Constructor, Property, and Method Injection. It discusses the benefits and challenges of DI, as well as the built-in DI container in .NET Core that simplifies dependency management. Additionally, it covers service lifetimes and key classes related to DI in .NET applications.

Uploaded by

dieptcnnde170171
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 54

Dependency Injection in .

NET
Objectives

Overview the SOLID Principles

Overview the Inversion of Control (IoC) pattern

Overview the Dependency Injection (DI)

Describe about Service Lifetimes in DI

Describe about Dependency Injection patterns

Describe about Advantages and Disadvantages of DI patterns

Demo about IoC pattern

Demo about DI pattern: Constructor, Property, Method and Ambient
Context
04/24/2025 2
Overview The SOLID Principles
Understanding The SOLID Principles

The SOLID principles were developed by Robert C. Martin in a 2000 essay,
“Design Principles and Design Patterns,” although the acronym was coined later
by Michael Feathers

SOLID is a popular set of design principles that are used in object-oriented
software development

SOLID is an acronym that stands for five key design principles: single
responsibility principle, open-closed principle, Liskov substitution principle,
interface segregation principle, and dependency inversion principle

All five are commonly used by software engineers and provide some important
benefits for developers
04/24/2025 4
Understanding The SOLID Principles

The following diagram schematizes the five principles' initials and
correspondences:

04/24/2025 5
Understanding The SOLID Principles

S - Single Responsibility Principle: A class should have only a single
responsibility (that is, only one potential change in the software's specification
should be able to affect the specification of the class)

O - Open/Closed Principle: Software entities should be open for extension, but
closed for modification

L - Liskov Substitution Principle: Objects in a program should be replaceable
with instances of their subtypes without altering the correctness of that program

I - Interface Segregation Principle: Many client-specific interfaces are better
than one general-purpose interface

D - Dependency Inversion Principle:
 High-level modules should not depend on low-level modules. Both should depend on
abstractions
 Abstractions should not depend upon details. Details should depend upon abstractions
04/24/2025 6
Single Responsibility Principle Demo
[
{
"Title": "Mastering C# and .NET 1
Programming",
"Author": "Marino Posadas",
"Price": 49.89
},
{
"Title": "F# Programming",
"Author": "Apress",
2 3
"Price": 33.91
}
]

04/24/2025 7
Single Responsibility Principle Demo
4 Install Newtonsoft.Json package from NuGet

5 Program.cs

04/24/2025 8
Open/Closed Principle Demo
1

4
3

04/24/2025 9
Open/Closed Principle Demo

04/24/2025 10
Open/Closed Principle Demo
6 Program.cs

04/24/2025 11
Liskov Substitution Principle Demo

04/24/2025 12
Liskov Substitution Principle Demo
IBook.cs
Utilities.cs

Book.cs

04/24/2025 13
Liskov Substitution Principle Demo
Program.cs

04/24/2025 14
Liskov Substitution Principle Demo

04/24/2025 15
Interface Segregation Principle Demo

04/24/2025 16
Interface Segregation Principle Demo

04/24/2025 17
Interface Segregation Principle Demo

04/24/2025 18
Interface Segregation Principle Demo
Program.cs

04/24/2025 19
Interface Segregation Principle Demo

04/24/2025 20
Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should
depend on the abstraction

Abstractions should not depend on details. Details should depend on
abstractions


Notification depends on Email, creating an instance in its constructor. This kind
of interaction is said to be tightly coupled. If we want to send other types of
notification as well, we have to modify the way the Notification class is
implemented
04/24/2025 21
Understanding Inversion of Control (IoC)

Inversion of Control (IoC) is a design principle. As the name suggests, it is used to
invert different kinds of controls in object-oriented design to achieve loose coupling

The controls refer to any additional responsibilities a class has, other than its main
responsibility. This include control over the flow of an application, and control over
the flow of an object creation or dependent object creation and binding

The IoC principle helps in designing loosely coupled classes which make them
testable, maintainable and extensible

The DIP is a principle or set of rules
kind of theory. On the other hand,
Inversion of Control is a pattern of
well-defined steps we can follow to
make our code DIP friendly
04/24/2025 22
Understanding Inversion of Control (IoC)

The direction of dependency within the
application should be in the direction of
abstraction, not implementation details.
Most applications are written such that
compile-time dependency flows in the
direction of runtime execution, producing
a direct dependency graph

That is, if class A calls a method of class
B and class B calls a method of class C,
then at compile time class A will depend
on class B, and class B will depend on
class C, as shown in the figure
04/24/2025 23
Understanding Inversion of Control (IoC)

Applying the Dependency Inversion
Principle (DIP) allows A to call methods on
an abstraction that B implements, making it
possible for A to call B at runtime, but for B
to depend on an interface controlled by A at
compile time (thus, inverting the typical
compile-time dependency)

At run time, the flow of program execution
remains unchanged, but the introduction of
interfaces means that different
implementations of these interfaces can
easily be plugged in
04/24/2025 24
IoC Pattern Demo
[ <Movies>
{ <Movie>
"ID": "1", <ID>3</ID>
"Title": "Jurassic <Title>King Kong</Title>
Park",
"OscarNominations": <OscarNominations>4</OscarNominations>
"3", <OscarWins>3</OscarWins>
"OscarWins": "3" </Movie>
}, <Movie>
{ <ID>5</ID>
"ID": "2", <Title>Superman Returns</Title>
"Title": "Spider-Man",
"OscarNominations": <OscarNominations>1</OscarNominations>
"2", <OscarWins>0</OscarWins>
"OscarWins": "0" </Movie>
} </Movies>
]

04/24/2025 25
IoC Pattern Demo

04/24/2025 26
IoC Pattern Demo

04/24/2025 27
IoC Pattern Demo
Program.cs

04/24/2025 28
Overview Dependency Injection
Understanding Dependency Injection (DI)

IoC can be done using Dependency Injection (DI). It explains how to inject the
concrete implementation into a class that is using abstraction, in other words an
interface inside

The main idea of dependency injection is to
reduce the coupling between classes and
move the binding of abstraction and
concrete implementation out of the
dependent class. In simple words, DI is how
one object know about other dependent
object which is abstracted. There are
mainly 04 ways of achieving the
Dependency Injection:
04/24/2025 30
Benefits of Dependency Injection (DI)
Benefit Description When is it valuable?
Valuable in standard software, but perhaps
Services can be swapped with other
Late binding less so in enterprise applications where the
services
runtime environment tends to be well-defined
Code can be extended and reused in ways
Extensibility Always valuable
not explicitly planned for
Parallel Valuable in large, complex applications; not so
Code can be developed in parallel
development much in small, simple applications
Classes with clearly defined responsibilities
Maintainability Always valuable
are easier to maintain
Only valuable if you unit test (which you really,
Testability Classes can be unit tested
really should)

04/24/2025 31
Dependency Injection in .NET (.NET Core)

We can implement Dependency Injection manually by using one or more of the
patterns. However, .NET Core comes with a built-in DI Container that simplifies
Dependency Injection management

A DI Container is a software library that can automate many of the tasks involved in
composing objects and managing their lifetimes

The DI Container is responsible for supporting automatic Dependency Injection. Its
basic features include:
 Registration: the IoC Container needs to know which type of object to create for a specific
dependency; so, it provides a way to map a type to a class so that it can create the correct
dependency instance
 Resolution: this feature allows the IoC Container to resolve a dependency by creating an
object and injecting it into the requesting class
 Disposition: the IoC Container manages the lifetime of the dependencies following specific
criteria
04/24/2025 32
Service Lifetimes

When dealing with an object's lifetime, .NET Core presents three types,
depending on the way instances will be configured and used: Singleton, Scoped,
and Transient

The Singleton option, a unique instance of the
object is used (meaning that we only manage a
reference to the object). Any further request uses
the same instance, according to the singleton
pattern

The Scoped version is local to the context in which
it is used and doesn't extend beyond that context

The Transient option creates a new instance of the
class every time is requested
04/24/2025 33
The Microsoft.Extensions.DependencyInject Container

NET Core offers its own container linked to the external library
Microsoft.Extensions.DependencyInjection (now, in version 5.0), we'll have to
reference it via NuGet packages to implement DI in the .NET applications

The following table describes some of the key classes:
Class Description
ActivatorUtilities Helper code for the various activator services
Default implementation
DefaultServiceProviderFactory
of IServiceProviderFactory<TContainerBuilder>
ServiceCollection Default implementation of IServiceCollection
Options for configuring various behaviors of the
ServiceProviderOptions
default IServiceProvider implementation
HttpClientBuilderExtensions Extension methods for configuring an IHttpClientBuilder
Extensions methods to configure
HttpClientFactoryServiceCollectionExtensions
an IServiceCollection for IHttpClientFactory
04/24/2025 34
ServiceCollection Class Demo
Install package from
NuGet

04/24/2025 35
ServiceCollection Class Demo
Program.cs

04/24/2025 36
Understanding Dependency Injection Patterns

The following are the four important patterns by which we can implement
Dependency Injection (DI):

04/24/2025 37
DI - Constructor Injection Pattern

How do we guarantee that a necessary dependency is always available to the
class we’re currently developing?

By requiring all callers to supply the dependency as a parameter to the class’s
constructor
NeedyClass needs an instance of
Dependency to work, so it requires any
Client to supply an instance via its
constructor. This guarantees that the
instance is available to NeedyClass
whenever it’s needed


When a class requires an instance of a dependency to work at all, we can supply
that dependency through the class’s constructor, enabling it to store the reference
for future (or immediate) use
04/24/2025 38
DI - Constructor Injection Pattern Demo

04/24/2025 39
DI - Constructor Injection Pattern Demo
Program.cs

04/24/2025 40
DI - Constructor Injection Pattern

Advantages of the Constructor Injection pattern
 This is the most preferable way of respecting the concept of DI. Most DI containers target the
constructors. It is also the most common and more widely used pattern for DI. The injected
component can be used anywhere in the class because when we create the object, the injected
dependency comes into the class automatically and stays in some variable
 Developers prefer this technique when classes require some external dependency to initiate all
other operations. As a constructor is involved, an object becomes ready with the dependent object
once it is instantiated

Disadvantages of the Constructor Injection pattern
 This is not so easy to implement when the class contains many constructors.
Moreover, when the number of dependencies increases for a class, updating the
constructor each time is not a feasible task
 When we have a number of arguments for a constructor by adding the dependency
ones with the existing ones, the class will look messy
04/24/2025 41
DI - Property Injection Pattern

How do we enable DI as an option in a class?

By exposing a writable property that lets callers supply a dependency if they wish to

override the default behavior


SomeClass has an optional
DEPENDENCY on ISomeInterface;
instead of requiring callers to supply
an instance, it’s giving callers an
option to define it via a property


The diagram depicts one property
EmployeeDept, which can be injected
directly with an IDepartment implementation

04/24/2025 42
DI - Property Injection Pattern Demo

04/24/2025 43
DI - Property Injection Pattern Demo
Program.cs

04/24/2025 44
DI - Property Injection Pattern

Advantages of the Property Injection pattern
 It does not require adding a new constructor or modifying an existing constructor
 This pattern comes in handy if the class has multiple dependencies of different types

Disadvantages of the Property Injection pattern
 Setters are not easy to identify in a particular design to inject some external dependency. Still,
they are preferred in some situations. However, we should be careful while using the property
which is injected because that might be null. There should be an extra check for null,
everywhere where you want to use it
 Property Injection is considered as bad practice in most of the cases because it hides the
dependencies. When the class is instantiated, there is no guarantee that the dependency object
will be available for the class to do any operation, unlike Constructor Injection, where the
dependency makes its way through during instantiation itself

04/24/2025 45
DI - Method Injection Pattern

How can we inject a Dependency into a class when it’s different for each
operation?

By supplying it as a method parameter

A Client creates an instance of


SomeClass, but first injects an
instance of the DEPENDENCY
ISomeInterface with each method
call


When a dependency can vary with each method call, we can supply it via a
method parameter

Advantages : Allows the caller to provide operation-specific context

Disadvantages: Limited applicability
04/24/2025 46
DI - Method Injection Pattern Demo
Install package from
NuGet

04/24/2025 47
DI - Method Injection Pattern Demo
Program.cs

04/24/2025 48
DI - Ambient Context

How can we make a Dependency available to every module without polluting every
API with Cross-Cutting Concerns?

By making it available via a static accessor

Every module can access an Ambient Context if it needs


to

04/24/2025 49
DI - Ambient Context Demo

04/24/2025 50
DI - Ambient Context Demo

04/24/2025 51
DI - Ambient Context
Program.cs

04/24/2025 52
DI - Ambient Context

Advantages of the Ambient Context
 Ambient Context is definitely a savior when an app demands the same dependency
multiple times during the app execution. It's very hard to realise the fact that while we
write codes for injecting dependencies, there are many such instances of asking the
same dependency repeatedly within the app. This is the time where we should take the
help of the Ambient Context Pattern, and with just a simple static accessor, we will be
able to get the dependency. This not only reduces code but also imposes the DRY
principle

Disadvantages of the Ambient Context
 Ambient Context is not easy to implement and needs careful attention while using it. By
just looking at a class, we can't tell whether it implements the Ambient Context Pattern or
not. If the context changes in between execution, the outcome will be different, resulting
in side effects
04/24/2025 53
Summary

Concepts were introduced:
 Overview the SOLID Principles
 Overview the Inversion of Control (IoC) pattern
 Overview the Dependency Injection (DI)
 Describe about Service Lifetimes in DI
 Describe about Dependency Injection patterns
 Describe about Advantages and Disadvantages of DI pattern
 Demo about IoC pattern
 Demo about DI pattern: Constructor, Property, Method and Ambient Context
54

You might also like