Clean up the Application package's DI surface#347
Merged
Conversation
… plumbing, and hoist pipeline allocations
… them, and document the two-level registration model
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
AddApplication()/AddHandlers()(guaranteed-throw) andAddFluentValidation()(silent no-op) overloads outright — maintainer-approved given no external consumer of this package exists
yet — instead of obsoleting them; fix the "atleast" typo in the shared exception text on the surviving
AddHandlers(HandlerOptions).*REMOVED*markers, and anew CompatibilitySuppressions.xml suppresses the resulting CP0002 findings against the 1.1.0 baseline.
IRequestHandlerBase's untypedHandleAsync(object, ...)wrapper andNotificationHandlerExecutor.HandlerInstance(written, never read).PipelineHandlerDecoratormaterializes its reversed behavior chain onceper scoped instance; the domain-event wrapper drops the same LINQ overhead where correctness allows;
RequestLoggingPipelineBehavior/DomainEventLoggingPipelineBehaviorhoisttypeof(...).Nameto staticreadonly fields.
FluentValidationAssemblies/HandlerAssembliesinstead of reallocating a read-only copy on everyaccess; document the two-level registration model —
AddApplication(Action<ApplicationOptions>)is thehost's composition entry point, while
AddHandlers(Action<HandlerOptions>)andAddFluentValidation(Action<FluentValidationOptions>)are supported modular entry points a project thatdoesn't own the host can call directly and additively — in XML remarks and a new docs/articles/cqrs-pipeline.md
subsection; add the missing
= defaulttoIDomainEventPublisher.PublishAsync'sCancellationTokenparameters (PublicAPI.Shipped.txt text-only edit).
Verification
referenced the removed members.
Vulthil.SharedKernel.Application.Tests: 29/29 passed on net9.0 and net10.0, including a new test provingAddApplication+ a second module'sAddHandlers/AddFluentValidationcalls compose additively withoutduplicating the shared
ISender/IDomainEventPublisherregistrations.dotnet pack -c Release(fresh obj/bin) forVulthil.SharedKernel.Application: succeeded withthe CompatibilitySuppressions.xml in place; reproducibly failed with 6 CP0002 errors without it.
PublishAsynclines gaining= default(System.Threading.CancellationToken); the three removed members are marked inPublicAPI.Unshipped.txt instead.
Backport to v1.0: no — removals and guidance ship with the next minor.