-
Notifications
You must be signed in to change notification settings - Fork 383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplified usage of BindingContext resolved command handlers #1358
base: main
Are you sure you want to change the base?
Changes from all commits
d556325
2f2796b
b811921
b050e7a
5db4df8
765d3a5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -282,6 +282,10 @@ public static ICommandHandler Create<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T1 | |
Func<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, Task<int>> action) => | ||
HandlerDescriptor.FromDelegate(action).GetCommandHandler(); | ||
|
||
public static ICommandHandler FromBindingContext<THandler>() | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It might be helpful for the naming to reflect that the actual handler will be created during binding. One not great idea to open up discussion: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
where THandler : ICommandHandler => | ||
Create((InvocationContext context, THandler handler) => handler.InvokeAsync(context)); | ||
|
||
internal static async Task<int> GetExitCodeAsync(object value, InvocationContext context) | ||
{ | ||
switch (value) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One concern I have with this approach is that all handler registrations for all subcommands will happen regardless of which subcommand was used, when only one subcommand is ever used. This can be a bit wasteful and is part of why we've generally steered away from the common pattern for longer-lived apps where DI is configured up front but the cost is amortized over a longer lifetime. This is very often not the case for command-line apps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jonsequitur In this case (using the lazily bound registration) only the registration is added, no instance of
BindingContextCommandHandler1
norBindingContextCommandHandler2
is actually created at this point. And neither does the call toCommandHandler.FromBindingContext
. The actual instance is first created when the command handler for the choses command is invoked.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood. At invocation time though, all of these registrations happen on the
BindingContext
, and coupled with the addition of non-lazyAddService
calls, this encourages the pattern I mentioned above.