Add readme "How To Implement Dependency Injection with Pure.DI code generator" #541
Conversation
…enerator" - adds sidebar menu item
…enerator" - minor
|
Is there a reason this can't be added to the main DI article? There is a lot of overlap between them. Although other people may disagree about merging it. |
| string Greetings { get; } | ||
| } | ||
|
|
||
| public class MainViewModel(IBusinessService businessService) |
There was a problem hiding this comment.
Primary constructors are a fairly new feature. They should probably be avoided for now to ensure anybody copying and pasting the code can use it without worrying about their language version.
| void RegisterSomething(); | ||
| } | ||
|
|
||
| public class Repository: IRepository |
There was a problem hiding this comment.
Fix the formatting on this line
| This will be useful if the main window will require dependencies to be injected. | ||
|
|
||
| Advantages over classical DI container libraries: | ||
| - No explicit initialisation of data contexts is required. Data contexts are configured directly in `.axaml` files according to the MVVM approach. |
There was a problem hiding this comment.
I am not clear how what you have done is any different from the MS DI example. You are still explicitly resolving things from the container, just with more steps. This also sounds like you are implying the MS DI approach violates MVVM somehow?
There is also really nothing stopping you from setting up MS DI in a similar way. It just requires slightly more effort (and also a static locator).
|
|
||
| - You can set a shared resource as a data context | ||
|
|
||
| `DataContext="{StaticResource Composition}"` |
There was a problem hiding this comment.
This may(?) cause side effects when running inside the previewer, as the previewer will run your real app code. You really should have a separate set of test services that sets the design time data context
|
|
||
| Advantages over classical DI container libraries: | ||
| - No explicit initialisation of data contexts is required. Data contexts are configured directly in `.axaml` files according to the MVVM approach. | ||
| - The code is simpler, more compact, and requires less maintenance effort. |
There was a problem hiding this comment.
This is fairly opinionated, which I would argue does not belong in a tutorial like this. You should present facts and let people make their own decision
| `Title="{Binding MainViewModel.Title}"` | ||
|
|
||
| Advantages over classical DI container libraries: | ||
| - The code-behind `.cs` files for views are free of any logic. |
There was a problem hiding this comment.
There are many ways to do DI without using a static locator or putting any DI logic on code behind that work in basically every DI framework. The original example code for MSDI mentioned one possible way, it was just removed due to the lack of practical examples in the guide.
|
|
||
| Advantages over classical DI container libraries: | ||
| - No performance impact or side effects when creating composition of objects. | ||
| - All logic for analyzing the graph of objects, constructors and methods takes place at compile time. Pure.DI notifies the developer at compile time of missing or cyclic dependencies, cases when some dependencies are not suitable for injection, etc. |
There was a problem hiding this comment.
This paragraph is just an elaborated version of the previous one
No description provided.