Zend Di vs ServiceManager Dependency-Injektion Container

Was ist DI für und was ist ihr Anwendungsfall, wenn wir ServiceManager haben?Zend Di vs ServiceManager Dependency-Injektion Container

Sie erscheinen da in Konfigurationsdateien ähnlich zu sein, sowohl für zend-di und zend-servicemanager wir einige Optionen wie aliases und invokables einrichten.

Ich versuche zu verstehen, was hinter den Kulissen mit diesen Komponenten passiert, und die Dokumentation gab mir nicht genug Informationen.

Können Sie mir bitte sagen, was der Unterschied ist und wann ich Di anstelle von ServiceManager verwenden sollte?

Quelle

2012-11-06 user1650441

Es gibt eine gute Diskussion über Behälter im Allgemeinen auf http://www.php-fig.org/psr/psr-11/meta/ – Dennis

moderner Ratschlag scheint zu sein, "benutze DI oder SM nicht" selbst, es sei denn, sie sind bereits Teil deines Rahmens. Zend verwendet den Factory-basierten Service Manager (der im Wesentlichen ein eingeschränkter DI-Container ist), in dem Sie darauf achten müssen, dass kein Container in eine Ihrer eigenen Klassen injiziert wird. Sie können den Container jedoch als Teil Ihrer Einrichtung verwenden Anwendung. in Zend können Sie Einrichtungen des Frameworks selbst verwenden, um anzupassen, wie Ihre Abhängigkeiten verdrahtet sind. Einige aktuelle Beispiele finden Sie hier: https://docs.zendframework.com/tutorials/getting-started/database-and-models/ – Dennis

Zend \ DI beruht auf Magie, wie Reflexionen, um Abhängigkeiten zu erkennen und zu injizieren, während der Service Manager vom Benutzer bereitgestellte Fabriken verwendet. Das ist der Hauptunterschied.

Diese Art von veraltet in der Community zugunsten von SM aufgrund von Komplexität, Debugging und Leistungsprobleme. Es sollte gut für RAD sein, aber Sie brauchen überdurchschnittliches Wissen, um es richtig zu verwenden.

Auf der anderen Seite SM haben ziemlich ausführliche und explizite Verkabelung, können Sie Ihren Code Jahr später öffnen und leicht herausfinden, was vor sich geht.

Quelle

2012-11-06 21:04:52 Xerkus

Das ist eine gute Antwort, ich erinnere mich, dass ich DI schon früh benutzt habe und ich würde es nicht mehr benutzen . – DrBeza

bedeutet es, dass ich weigere mich di zu benutzen und sm wird die arbeit auch machen? – user1650441

Genau wie Xerkus darauf hingewiesen hat. Di-Stuff gilt als deprecated, DI-Container waren einfach zu komplex. Der ServiceManager löst das gleiche Kernproblem auf eine wesentlich benutzerfreundlichere Art und Weise. – Sam

Zend\Di kümmert sich um die Verdrahtung Ihrer Klassen zusammen, während mit Zend\ServiceManager müssen Sie Dinge manuell verdrahten und schreiben eine Fabrik Schließung für jede Klasse, die Sie instanziieren möchten.

Zend\ServiceManager ist viel schneller, da es nicht auf die langsame Reflection API angewiesen ist. Auf der anderen Seite wird das Schreiben von Schließungen für große Anwendungen mit Hunderten von Klassen sehr mühsam. Halten Sie Ihre Schließungen up-to-date wird immer kniffliger als Ihre Anwendung wächst.

Um dieses Problem zu beheben, habe ich ein Zend Framework 2-Modul namens ZendDiCompiler geschrieben. Es basiert auf Zend\Di, um Ihren Code zu scannen, und generiert automatisch den Factory-Code, um Ihre Klassen zu instanziieren. Sie erhalten das Beste aus beiden Komponenten: die Leistung von Zend\Di und die Leistung von Zend\ServiceManager.

Ich habe ziemlich viel Arbeit in die Dokumentation von ZendDiCompiler gesteckt und einige einfache und erweiterte Anwendungsbeispiele werden ebenfalls zur Verfügung gestellt.

Quelle

2013-03-09 20:29:12 aimfeld

Grundsätzlich ist der Unterschied wie folgt:

Zend\ZerviceManager = Werks angetrieben IoC Container
Zend\Di = autowiring IoC Implementierung

Zend\Di wurde Überarbeitete für Version 3. Sein Verhalten jetzt fester und vorhersagbar als v2 und es ist entworfen, um sich nahtlos in zend-servicemanager zu integrieren, um Autoverdrahtungsfähigkeiten zur Verfügung zu stellen (keine ungerade Magie). Da PHP reflection API verwendet, um Abhängigkeiten aufzulösen, ist es langsamer als ein Factory-Driven-Ansatz. Daher enthält Version 3 einen AoT-Compiler, um einen voraufgelösten Injektor zu erstellen, der die Verwendung von Reflection auslässt. Ein zusätzlicher Vorteil: Die generierten Fabriken können auch direkt mit Zend\ServiceManager verwendet werden.

Es ist ein Leitfaden für AoT Verwendung mit beiden Komponenten: https://zendframework.github.io/zend-di/cookbook/aot-guide/

Quelle

2018-02-26 10:55:39 Axel

Zend Di vs ServiceManager Dependency-Injektion Container

Antwort

Verwandte Themen