Chain of Responsibility Design Pattern in C#

The article presents Chain of Responsibility as a behavioral pattern for splitting a complex task into independent handlers linked in sequence. It uses ASP.NET Core middleware and a library rental request as the main examples, then shows how to move from a monolithic service to separate handler classes.

Reading notes

#

• The pattern passes a request through a chain of handlers, and each handler decides whether to process the request or forward it to the next one.
• It is presented as useful for breaking logic into smaller parts, each with its own responsibility, which favors low coupling and the Single Responsibility Principle.
• The text points to ASP.NET Core middleware as a direct example of this pattern, because multiple handlers can treat the same request independently.
• In the general description, the chain is formed by the client, which organizes the handlers in sequence and starts execution at the first one.
• The article distinguishes a flow with multiple handlers, in which the request can advance through several stages, from a flow with a single effective handler, in which the chain only continues until it finds the appropriate handler.
• In the library example, a monolithic RentalAssistService brings together book availability checks, member eligibility, balance, and issuance, which leaves the class coupled and difficult to evolve.
• The proposed refactoring turns each stage into an independent handler and links these handlers with a SetNext() method that stores the reference to the next one.
• The example code shows a BookAvailabilityCheckHandler that validates the book’s availability and, if there is a next handler, forwards the request onward.
• The complete flow assembles the chain with availability check, member access check, balance check, and book issuance.
• The article highlights that the client then only takes care of the order of the handlers and the initial Handle() call.
• An implicit use of the pattern is to build a smaller chain to only evaluate the request, without reaching the book issuance stage.
• Among the problems, the text mentions the need to define the order of the handlers well, because a validation stage placed after a processing stage can let an invalid request advance.
• It also points out that passing states between handlers can increase complexity and create coupling between stages.
• Another risk is that the request may not be handled by any handler, if they all only forward execution.