How not to violate SOLID?

Question

PHP

The router works like this:

[
        'pattern' => '~^/news/([a-zA-Z0-9\-]+)$~',
        'class' => 'vendor\app\Frontend\Controllers\News',
        'method' => 'getSingle',
        'params' => ['news_url'],
],

We have a class, method and parameter.
Next, the Controller Resolver creates a controller object and off we go.
In the controller, respectively, there are dependencies, the most banal is the model.
If it is correct to depend on abstractions and not on concrete classes (do not create objects in the constructor),
will it be correct to pass dependencies in routing , for example something like this:

[
        'pattern' => '~^/news/([a-zA-Z0-9\-]+)$~',
        'class' => 'vendor\app\Frontend\Controllers\News',
        'method' => 'getSingle',
        'someDependencies'=>['vendor\app\Frontend\Models\News', 'vendor\app\Common\AccessControl'],
        'params' => ['news_url'],
],

Or is there a better way out?

Answer 1

You are confusing Inversion of Control and Inversion of Dependency. Let's take it short.
Why do we need a controller at all? What is he doing? For the sake of simplicity, don't think of the controller as a "single object" and instead think of it as a whole layer. Let's also replace the word "model" with the word "application".
The task of the controller is to accept and process the request and issue a response. Essentially, in the WEB context, our HTTP request and response is the representation that the client (browser, mobile app, SPA, whatever) wants to receive. HTTP is the user interface (UI) for our web application.
2016-07-14T19:40:12Z ). This is convenient to be independent of the client or server implementation. But this is not convenient for our application. In an application, it is most likely that we are most comfortable working with an object of type DateTime. That is, the application uses a completely different representation.
We could convert DateTime to iso 8601 right in the application, but then we make our application tied to one specific view that the client wants to receive. For example, for some reason known only to the dark gods, you suddenly need to quickly screw up integration with another service and drive the same data already in RFC2822. And so the application needs to worry about one more view.
We could make some adapters in the application, and pull them depending on the needs, but then again, our application still knows about the view, which it does not actually need. So we have an application's dependency on its UI which... sounds like "not a good idea". And here Inversion of Control comes to the rescue.
Here the name speaks for itself. Let's say we had an object A that pulled an object B , and the object A , in fact, should not know anything about the object B, because it's none of his business. The principle of inversion of control tells us that in such situations it is B that should call A, thus changing the direction of control flow. This allows us to reduce coupling and increase the cohesion of the components of our system. Having also done this, we may have an object C that will also pull the object A . If we talk about UI - we can just make several UI implementations.
That is, to simplify it further, the framework should pull your code, and not the code pull the framework code. Thus, we reduce the connectivity of one from the other.
To decouple the application from the presentation generation logic, let's put it all in a separate "layer" and call this layer controllers. More precisely, it will be like a chain of adapters. One adapter (essentially a front controller) receives the Request and does some stuff with it. For example, it checks whether we can make such a request at all. Another adapter calls the router and finds out which adapter to call next. If the next adapter is not called, return a 404 error. If everything went well, we call another adapter, which will already convert the HTTP request into some kind of application action (calling the application method, in fact).
Dependency inversion is very similar to inversion of control, but it works a little differently. It will be easiest to look at the picture:
the dependency arrow on the first figure goes beyond our "module" and climbs into the "alien", thus our module becomes dependent on another module. A striking example - we have for example SwiftMailer for sending mail. Our code just needs a way to send messages, and SwiftMailer is just a concrete implementation.
If we do not want to be tied to SwiftMailer, and give the opportunity to change the way mail is sent in the future, we can declare an interface within our module and implement it in another module using SwiftMailer. For simplicity, by modules we can understand namespaces, for example.
This is already a question of the IoC implementation. Specifically, you want to get something like Dependency Injection. You can pick up dependencies from action method arguments. or controller constructor arguments.... or just use a dependency container inside the controller.... it doesn't matter at all. Controllers are where high coupling to framework components is more than acceptable.
On the other hand, you now have routing that combines the responsibility of routing and debugging. You understand that this somehow violates the principle of single responsibility. Some Controller Resolver can do this.