Post History

Chain of Responsibility doesn't strike me as appropriate for this problem, at least as I understand it. You want to use CoR if you have multiple different requirements for the processing of the same data—authentication, logging, A-B testing—things we generally call concerns. What it sounds like you're going to have is a large data structure where you want to process each of the pieces of that data structure individually and then commit the entire job in a single transaction. CoR is overkill for that; just have your payload object have a field for each logical section and have a function for handling each section. You can call those functions directly or over a mediator, depending on your other requirements.

In this scenario, your biggest maintenance worry is going to be how truly isolated each section's handler is from the others. If your DTO looks like

```c#
class Section1 {
  public Group1 Group1 { get; set; }
  public Group2 Group2 { get; set; }
}
```

but your handler for `Group2` requires data from `Group1`, you'll have coupling that'll make it harder to change the processing of each group individually. Chain of Responsibility would not help with this; in fact, it would obscure what you need to do, since every middleware processor would get the entire `Section1`. The way to stay on top of this worry is:
* try to keep the groups logically isolated
* when that fails, pass inter-group data explicitly to the functions that need them

If the first bullet point is a challenge due to what the business wants from the UI, consider an intermediate stage that adapts an entire view model class into a logical model class but doesn't do anything with side effects, and then dispatches the fragments of the logical model to your handlers. This adaptation also doesn't need to be done with CoR; it's necessarily coupled to the types of your application code and must be invoked the same way with every request, which makes it a bad fit for a design pattern intended to be largely data-agnostic and dynamic.