Skip to content

Commit bad307a

Browse files
Fix DI guide formatting and some awkward phrasing (#711)
* Update how-to-implement-dependency-injection.md * Update how-to-implement-dependency-injection.md * Fix typo
1 parent b52de64 commit bad307a

File tree

1 file changed

+9
-9
lines changed

1 file changed

+9
-9
lines changed

docs/guides/implementation-guides/how-to-implement-dependency-injection.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,7 @@ This guide will show you step by step how to use Dependency Injection (DI) with
1111

1212
## Step 0: Context and Initial Code
1313

14-
Let's assume that you have an app with a MainViewModel, a BusinessService and a Repository. MainViewModel has a dependency on IBusinessService and BusinessService on IRepository. A simple implementation would look like this:
14+
Let's assume that you have an app with a `MainViewModel`, a `BusinessService` and a `Repository`. `MainViewModel` has a dependency on `IBusinessService` and `BusinessService` on `IRepository`. A simple implementation would look like this:
1515

1616
```csharp
1717
public partial class MainViewModel
@@ -43,7 +43,7 @@ public class Repository : IRepository
4343
}
4444
```
4545

46-
Typically you would directly instantiate `Repository` and pass it into `BusinessService` then pass it into `MainViewModel`, like this:
46+
Traditionally, you would directly instantiate `Repository` and pass it into `BusinessService` then pass it into `MainViewModel`, like this:
4747

4848
```csharp
4949
var window = new MainWindow
@@ -52,12 +52,12 @@ var window = new MainWindow
5252
}
5353
```
5454

55-
This works great for simple constructors that are not used very often and don't change. But this technique does not scale very well because:
56-
- The more dependencies your constructor has the more things you will need to instantiate and pass in. Instantiating the dependencies locally (such as by doing new MainViewModel(new MyService())) results in direct rigid coupling to a specific instance of the dependencies.
57-
- Similarly if MainViewModel creates its dependencies itself, (such as in the constructor body) it also becomes directly coupled to the creation of the dependencies which can result in mostly the same problems.
58-
- Furthermore, if the object is instantiated in many places, every single reference to any of the dependencies would also need to be updated should the dependencies of `MainViewModel` ever change (such as by requiring additional dependencies or require a different implementation of a dependency).
55+
This works great for simple constructors that are not used very often and don't ever change. But this pattern does not scale well, because:
56+
- The more dependencies your constructor has the more things you will need to instantiate yourself and pass in. Instantiating the dependencies locally in the constructor (such as by doing `new MainViewModel(new MyService())`) results in direct rigid coupling to a specific instance of the dependencies.
57+
- Similarly if the `MainViewModel` constructor itself creates its own dependencies, it also becomes directly coupled to the creation of the dependencies which can result in many of the same problems.
58+
- Furthermore, if `MainViewModel` is instantiated in many places, _every_ instantiation of `MainViewModel` would also need to be updated should the dependencies of `MainViewModel` ever change (such as the addition of new dependencies, or changing which implementation of a dependency to use).
5959

60-
Dependency injection solves these problem by abstracting away the creation of objects and their dependencies. This allows for well encapsulated services to be used that will be automatically passed into any other service that is registered to use them.
60+
Dependency injection solves these problem by abstracting away the creation of objects and their dependencies. This allows for well encapsulated services that will be automatically passed into any other service that is registered to use them.
6161

6262
## Step 1: Install the NuGet package for DI
6363
There are many dependency injection (DI) container providers available ([DryIoC](https://github.com/dadhi/DryIoc), [Autofac](https://github.com/autofac/Autofac), [Pure.DI](https://github.com/DevTeam/Pure.DI)) but this guide will only focus on `Microsoft.Extensions.DependencyInjection` which is a lightweight, extensible dependency injection container. It provides an easy-to-use and convention-based way to add DI to .NET applications, including Avalonia-based desktop applications.
@@ -69,7 +69,7 @@ dotnet add package Microsoft.Extensions.DependencyInjection
6969
```
7070

7171
## Step 2: Add ServiceCollectionExtensions
72-
The following code is creating an extension method for `IServiceCollection` that will register services to our service collection and make them available for injection.
72+
The following code creates an extension method for `IServiceCollection`. The method will register services to the service collection and make them available for injection.
7373

7474
```csharp
7575
public static class ServiceCollectionExtensions
@@ -84,7 +84,7 @@ public static class ServiceCollectionExtensions
8484
```
8585

8686
## Step 3: Modify App.axaml.cs
87-
Next, the `App.xaml.cs` class should be modified to use the DI container. This will allow the previously registered view model to be resolved via the dependency injection container. The fully realised view model can then be set to the data context of the main view.
87+
Next: the `App.xaml.cs` class should be modified to use the DI container. This will allow the view model which was registered in the previous step to be resolved via the dependency injection container. The fully realised view model can then be set to the data context of the `MainWindow`/`MainView`.
8888

8989
```csharp
9090
public class App : Application

0 commit comments

Comments
 (0)