> For the complete documentation index, see [llms.txt](https://brightercommand.gitbook.io/paramore-brighter-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines.md). # Commands, Handlers and Pipelines - [Requests, Commands and Events](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/requests-commands-and-events.md): We use the term Request for a data object containing parameters that you want to dispatch to a handler. - [Dispatching Requests](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/dispatchingarequest.md): Once you have implemented your Request Handler, you will want to dispatch Commands and Events to it synchronously, through the Command Processor. - [Dispatching an Async Request](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/dispatchingarequest/asyncdispatcharequest.md): Once you have implemented your async Request Handler, you will want to dispatch Commands and Events to it through the Command Processor's asynchronous methods. - [Returning Results from a Handler](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/dispatchingarequest/returningresultsfromahandler.md): We use Command-Query separation so a Command does not have a return value and CommandDispatcher.Send() does not return anything. - [How to Implement a Request Handler](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/implementingahandler.md): To implement a handler, derive from RequestHandler\ where T should be the Command or Event derived type that you wish to handle. - [How to Implement an Async Request Handler](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/implementingahandler/implementingasynchandler.md): To implement an asynchronous handler, derive from RequestHandlerAsync\ where T should be the Command or Event derived type that you wish to handle. - [Building a Pipeline of Request Handlers](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/buildingapipeline.md): Once Brighter is dispatching requests to your handlers, you can insert orthogonal operations into the pipeline that runs around each handler. - [Building an Async Pipeline of Request Handlers](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/buildingapipeline/buildinganasyncpipeline.md): An async pipeline wraps an async request handler in the same orthogonal operations a synchronous pipeline uses, with attributes whose handlers await. - [Passing Information Between Handlers in the Pipeline](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/buildingapipeline/usingthecontextbag.md): A key constraint of the Pipes and Filters architectural style is that Filters do not share state. - [Pipeline Validation and Diagnostics](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/buildingapipeline/pipelinevalidation.md): Brighter can validate your pipeline configuration at startup, catching common mistakes before any messages are sent or consumed. - [Request Validation](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/buildingapipeline/requestvalidation.md): Brighter can validate a request in its handler pipeline before your business handler runs. - [Feature Switches](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/buildingapipeline/featureswitches.md): We provide a FeatureSwitch Attribute and FeatureSwitchAsync Attribute that you can use on your IHandleRequests\.Handle() method, and IHandleRequests\.HandleAysnc() method. - [Supporting Retry and Circuit Breaker](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/buildingapipeline/policyretryandcircuitbreaker.md): Brighter is a Command Processor and supports a pipeline of Handlers to handle orthogonal requests. - [Migrating to Polly v8](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/buildingapipeline/policyretryandcircuitbreaker/migratingtopollyv8.md): Both tails of the Polly story in one place. - [Failure and Fallback](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/buildingapipeline/policyfallback.md): A Fallback is a backstop exception handler, which runs when a request has failed and lets you take compensating action. - [Agreement Dispatcher](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/agreementdispatcher.md): The Agreement Dispatcher is a pattern for routing requests to handlers dynamically based on the request's content or context, rather than using a fixed type-to-handler mapping. - [Agreement Dispatcher Routing](https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines/agreementdispatcher/agreementdispatcherrouting.md): Why you would route a request by its content rather than its type, what that buys you, and what it costs. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://brightercommand.gitbook.io/paramore-brighter-documentation/commands-handlers-and-pipelines.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.