dotnet / dotnet/command-line-api
Dependency Injection
- Dominant language
- C#
- Stars
- 3.7k
- Forks
- 428
- PR merge metrics
- No merged PRs in 30d
Description
I just read documentation because I have some need to easily be able to get access to a certain type of class from multiple commands.
I get some of the comments in regard to the need, and lifecycle etc of services running all the time... what I dont understand is the point of the Binder stuff. Is it only there to facilitate having a context to use for some of the command handling? (in the example of the logging stuff, to be able to let logger know the context in which some of its calls are made?)
Seems like I could just as easily do
```cs
.SetHandler((logger)=>{...}, instance>);
```
And that would be simpler and more concise than creating a binder for each and every type I want to be able to dynamically consume and then having to remember to effectively pass it to each and every place I may want to use it.
I've had no problems with the configuration of commands/subcommands options and arguments at all, but being able to organize functionality in my command line app seems to work better with something like some basic DI.
I feel like even if all it did was lazily instantiate a service as a singleton or something and inject same instance everywhere its specified as a dependency, that would be helpful.
Contributor guide
Assessment
This issue has not been assessed yet.