Move more code to zend-expressive-router?

[mtymek]

Since almost the beginning, I have a feeling that Application class does too much with routing, which breaks SRP. I thought that it is too late for architectural changes, but seeing that this package is being split today, I suggest moving more stuff away from this class, to zend-expressive-router package:

• adding routes (methods like route(), post() or get() can simply proxy to underlying router)
• checking for duplicated routes
• notifing about route result
• $routes property

[weierophinney]

The primary reasons we didn't do this has disappeared: container awareness. Originally, the routes would return the middleware, which meant the router needed awareness of the container; we were injecting it in the AppFactory.

However, there are other reasons we've kept the separation:

• route duplication checking. We are concerned about differences in behavior between different route implementations. While you largely cannot switch easily between route implementations due to differences in syntax, we don't want a situation where doing so fails due to differences in how each handles — or does not handle! — duplication detection. By keeping this in the application instance, we can control that behavior.
• having more than one object in which to inject routes (i.e., the get(), post(), etc. methods) leads to confusion (where should I do this? which one is better? why does one application do it in this place, and the other in this other place?). One huge goal for us is to make usage of Expressive follow poka-yoke principles; this largely means having one code path to accomplish something. (We already violate this somewhat by having HTTP method-specific routing methods, but having those on two objects would be worse.)
• route result notification makes the most sense at the application level. The problem with having it in the Router is that, again, we then have to depend on the implementation triggering the observers. Since the only part of the application workflow we can control is the Application instance itself, it makes sense to do this after the routing middleware obtains the RouteResult. (Due to that fact, I'm actually planning to move the RouteResultObserverInterface back into zend-expressive itself, since the code that triggers observers is in this repository.)

While I agree that some of these decisions break SRP, the reasons for doing so are largely to ensure that differences in router implementations do not lead to substantial differences in behavior. Doing so reduces maintenance costs significantly by removing edge cases.

[mtymek]

Thanks for your explanation - it makes sense for me now. Personally I would probably design it in different way, but I will leave this thoughts for v2.0 discussion, somewhere in the future :-)

[weierophinney]

@mtymek I'd also recommend reading this:

-zendframework/zend-expressive#216#issuecomment-162923176

as I think that gives a more thorough breakdown.

Essentially, Application is a facade, and facades are a specific case where SRP can and should be violated.