Welche Bedeutung hat die Implementierung der Di-Abhängigkeitsinjektion?

WBOY
Freigeben: 2016-08-18 09:15:27
Original
1017 Leute haben es durchsucht

Allgemeines PHP-Framework, der Lebenszyklus ist ungefähr so: Request > Dispatch > Natürlich kann es einige Unterschiede geben, aber die meisten davon sind nichts weiter.

Welche Bedeutung hat die Einführung von Di-Injektion? Sollen die am Bewerbungsprozess beteiligten Objekte in Komponenten umgewandelt werden, um eine Entkopplung zu erreichen? Wie RequestInterface/HttpRequest/CliRequest, RouterInterface/SimpleRouter/RegexRouter/MapRouter usw.?

Aber der allgemeine Prozess einer normalen Anfrage mit Ansicht und Datenbankbetrieb ist für alle gleich (ROR / J2EE / PHP MVC). Was bedeutet Entkopplung? ? Nachdem ich es gelöst habe, muss ich es noch herausnehmen und einen MVC-Prozess erstellen. Es ist, als ob der Router von der Anfrage abhängt. Wie wäre es also, wenn Sie sie manuell einfügen? Der Parameter des Router-Konstruktors ist RequestInterface $request? Welche Art von Anforderungsobjekt wird vom aktuellen Anwendungseintrag eingefügt? Ist es möglich, dass der Router eines Tages auf ein seltsames Gerät angewiesen ist?

Ist es nur zum Spaß, sich lustig zu machen? Oder ist es für die ungewisse Zukunft? Oder es gibt andere Gründe. . .

Antwortinhalt:

Allgemeines PHP-Framework, der Lebenszyklus sieht ungefähr so ​​aus: Request > Dispatch > Natürlich kann es einige Unterschiede geben, aber die meisten davon sind nichts weiter.

Welche Bedeutung hat die Einführung von Di-Injektion? Sollen die am Bewerbungsprozess beteiligten Objekte in Komponenten umgewandelt werden, um eine Entkopplung zu erreichen? Wie RequestInterface/HttpRequest/CliRequest, RouterInterface/SimpleRouter/RegexRouter/MapRouter usw.?

Aber der allgemeine Prozess einer normalen Anfrage mit Ansicht und Datenbankbetrieb ist für alle gleich (ROR / J2EE / PHP MVC). Was bedeutet Entkopplung? ? Nachdem ich es gelöst habe, muss ich es noch herausnehmen und einen MVC-Prozess erstellen. Es ist, als ob der Router von der Anfrage abhängt. Wie wäre es also, wenn Sie sie manuell einfügen? Der Parameter des Router-Konstruktors ist RequestInterface $request? Welche Art von Anforderungsobjekt wird vom aktuellen Anwendungseintrag eingefügt? Ist es möglich, dass der Router eines Tages auf ein seltsames Gerät angewiesen ist?

Ist es nur aus Spaß am Spotten? Oder ist es für die ungewisse Zukunft? Oder es gibt andere Gründe. . .

Meine Meinung zu DI war schon immer, dass es mehr um Abhängigkeitsmanagement als um Abhängigkeitsinjektion geht. Tatsächlich ähnelt es Composer, Pip, Maven und anderen übergeordneten Abhängigkeitsmanagement-Tools zwischen Anwendungen und Bibliotheken Bringt diese Vorteile (vorausgesetzt, ein gutes DI-Framework):

  1. Das Ändern der Implementierung abhängiger Schnittstellen durch Konfiguration ist auch die grundlegendste und Kernfunktion der DI-Funktion

  2. Kontrollieren Sie flexibel den Instanzumfang abhängiger Implementierungen, Singleton, eine pro Thread, eine pro Anfrage usw.

  3. Abhängige Parameter, abhängige Abhängigkeiten usw. Verwaltung

  4. Der Code ist prägnanter und die Logik ist klarer

  5. Mock ist praktisch zum Testen. Das geht ganz einfach mit 1

Im Allgemeinen geht es darum, die Abhängigkeiten zwischen Funktionsblöcken und Klassen in der Anwendung zentral über ein einheitliches Framework zu verwalten.

Das stimmt, es ist Entkopplung.
Ist die Entkopplung mit MVC abgeschlossen?
Ist dies die niedrigste Entkopplungsstufe?

Die Prämisse von DI ist, dass Sie einen einheitlichen Container zum Hosten Ihrer Beans benötigen. Wenn Sie über einen solchen Container verfügen, können Sie einige spezielle Operationen an den darin enthaltenen Beans durchführen, ohne den Code umfassend ändern zu müssen. ?

Die explizite Injektion ist entkoppelt und praktisch für Unit-Tests. Am schmerzhaftesten ist die implizite Injektion, bei der die Quelldatei lange Zeit nicht gefunden werden kann. Der DI von Laravel besteht eigentlich aus Anfragen und Diensten.

Verwandte Etiketten:
Quelle:php.cn
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage
Über uns Haftungsausschluss Sitemap
Chinesische PHP-Website:Online-PHP-Schulung für das Gemeinwohl,Helfen Sie PHP-Lernenden, sich schnell weiterzuentwickeln!