3 ms·

I'm not sure I see the benefit of creating a generic pipeline vs just having a "manager" class or function that calls each step in succession. The process of "l

I'm not sure I see the benefit of creating a generic pipeline vs just having a "manager" class or function that calls each step in succession. The process of "logging in" is conceptually a single step, thus it makes sense to have one unit that abstracts over the entire process. Factoring out the logic of successive calls into a pipeline doesn't seem very useful here. I could see a benefit if it were the case that each subprocess existed and is executed independently, but in the login case and probably most cases in general web development, this usually isn't true. To me, the benefit of a pipeline is when each filter can register itself (e.g. an event queue), thus the entity generating it has no knowledge of where it is going or who is processing it. A key indicator of this is when order of execution doesn't matter. In the case of logging in, order is critical so something somewhere must control the order each filter is ran. At this point you might as well have a unit that orchestrates this process itself.

ifyoubuildit 13y ago
What about the case where you would have multiple managers? For example, today you wrote a FooManager that handles all the Foos, next month you'll write a BarManager, and after that a BazManager and so on. Each of these will probably have a slightly different way of handling things... Creating pipelines for all of these scenarios seems like it would mean you're doing things consistently across your code base, which will hopefully make it easier to maintain. It also might make it easier to reuse code (you can share filters between different services).
- hackinthebochs 13y ago
  The problem I see with this is that the pipeline concept also constrains your code in other ways. For example, using the pipeline there is no clean way to allow communication between each successive subprocess. Return values in this case aren't clean (would involve casting), and mutating the data passed around seems like a cure worse than the disease. I know of no way to construct a generic pipeline that allows for all the flexibility of simply successive function calls. I suspect most problems won't cleanly fit the constraints imposed by a generic pipeline.
  - mrchuckmills2 13y ago
    > no clean way to allow communication between each successive subprocess I think this is much of the point behind this pattern, actually.

ifyoubuildit 13y ago

What about the case where you would have multiple managers? For example, today you wrote a FooManager that handles all the Foos, next month you'll write a BarManager, and after that a BazManager and so on. Each of these will probably have a slightly different way of handling things... Creating pipelines for all of these scenarios seems like it would mean you're doing things consistently across your code base, which will hopefully make it easier to maintain. It also might make it easier to reuse code (you can share filters between different services).

hackinthebochs 13y ago
The problem I see with this is that the pipeline concept also constrains your code in other ways. For example, using the pipeline there is no clean way to allow communication between each successive subprocess. Return values in this case aren't clean (would involve casting), and mutating the data passed around seems like a cure worse than the disease. I know of no way to construct a generic pipeline that allows for all the flexibility of simply successive function calls. I suspect most problems won't cleanly fit the constraints imposed by a generic pipeline.
- mrchuckmills2 13y ago
  > no clean way to allow communication between each successive subprocess I think this is much of the point behind this pattern, actually.