This is exactly how I handle most of my middleware as well — I have a project that uses the CQRS architectural pattern, and I decorate each command handler using this exact pattern.
I build the dependency graph in my dependency injection container, and use a mediator to dispatch commands to their (decorated) handlers. This is excellent for fine-tuned control over specific command handlers and their aspects. However, I can see a use for the PSR-15 style middleware — I see two different kinds of middleware: fine-grained middleware (some requests needs to be authenticated, some needs to be within a database transaction, maybe one or two requests result in an event that you need to fire off, etc), and the general middleware (you want to log all requests, you want to catch any exceptions and handle them appropriately, etc). I think the approach we are discussing here is ideal for fine-grained middleware — it makes the dependency graph explicit and easy to configure and maintain separately. PSR-15 is ideal for general middleware, which you can take a more functional approach to — there would (or should) only be a few layers, and they would apply to the application as a whole. Just my two cents. John On Apr 21, 2017, at 12:40 PM, Beau Simensen <[email protected]<mailto:[email protected]>> wrote: On Friday, April 21, 2017 at 10:42:11 AM UTC-5, Rasmus Schultz wrote: $kernel = new NotFoundMiddleware(); $kernel = new RouterMiddleware(new Router(...), $kernel); $kernel = new CacheMiddleware($kernel); $kernel = new ErrorHandlerMiddleware(); Off the top of my head, it feels like this would be difficult to automatically wire with a DI container since each middleware will need to be constructed with the previous middleware already instantiated. Especially given you cannot have consistent known arguments, this will be difficult to automate. return $this->container->get($id)->process($request); I think you tried to address this with the ContainerProxyMiddleware but it skips the construction part. How would the container know which $kernel to use in the constructor for the object at $id? This looks nice, API-wise, but it is ignoring how this object would actually be constructed. One of the things we did with Stack was required the first argument to always be the kernel and any additional arguments (if any at all) would have to follow after that. We used Stack Builder to help try and solve those problems. It still seemed messy and I was never very happy with it. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To post to this group, send email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/99e602d1-e871-4d19-829a-1330252b508c%40googlegroups.com<https://groups.google.com/d/msgid/php-fig/99e602d1-e871-4d19-829a-1330252b508c%40googlegroups.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/57FC4BBE-38F8-4B7D-B02D-1E003A0B7D21%40buffalo.edu. For more options, visit https://groups.google.com/d/optout.
