Ioc-Container und dynamische Sprachen (Take 2)

Question

Ich habe eine Menge über Dependency Injection, Inversion of Control und IoC-Container gelesen. Ich programmiere auch hauptsächlich in dynamischen Sprachen (PHP bei der Arbeit, Python zu Hause). Hier sind die Dinge, die ich finde, aber das lässt eine Menge Lücken für mich zu füllen, wie ich Stück es alle zusammen:

• Warum sind IOC-Container bei dynamischen Sprachen unnötig?
• Warum brauche ich einen IoC-Container im Gegensatz zu einfachem DI-Code?
• Vorteile eines IoC-Containers, die über eine einfache DI hinausgehen (Blogbeitrag)

Was ich also lese, ist: IoC-Container sind in statischen Sprachen eine viel größere Sache, weil es so viel einfacher ist, DI in dynamischen Sprachen durchzuführen. Aber sie bieten auch Vorteile, die weit über DI hinausgehen, wie z. B. die Verwaltung von Abhängigkeiten und die Ersparnis, ein Dutzend Objekte von Hand zusammenstellen zu müssen. Und, nebenbei bemerkt, sie sind kompliziert, also versuchen Sie nicht, sie selbst zu machen (aber es gibt keine guten für PHP).

Ich habe das Gefühl, dass diese Informationen mich irgendwie... feststecken lassen. Was soll ich damit machen? Ich arbeite in einer sehr großen Codebasis, mit sehr komplizierten Abhängigkeiten (und wahrscheinlich eine starke Notwendigkeit für Refactoring, aber das ist ein anderes paralleles Thema). Wir haben DI bisher sehr schlecht implementiert, und ich versuche wirklich, uns in die richtige Richtung zu lenken. Es scheint einfach nichts zu geben, was dynamische Sprachen und IoC (oder zumindest IoC-Container) betrifft.

Bin ich besser aus "Hand-stringing" Abhängigkeiten zusammen für die Zeit, und Sorgen über die Automatisierung in einem Container später, nachdem ich einen besseren Griff auf die Prinzipien? Lohnt es sich, meinen eigenen einfachen IoC-Container zu implementieren? Oder ist der Nutzen in PHP die Kosten letztlich nicht wert?

Answer 1

Für PHP versuchen Sie Symfony-Abhängigkeitsinjektion . Es basiert (angeblich - ich habe zu wenig Erfahrung, um das zu bestätigen) auf der Funktionsweise von Java Spring, verwendet aber auch eine Menge PHP-'Magie'. Als Ergebnis ist es ziemlich leicht und einfach zu bedienen, während in der Lage, eine ganze Menge zu tun.

Answer 2

Beheben Sie zunächst Ihre Abhängigkeitsprobleme. Wenn Sie einen IoC-Container als Tasche, die mit Ihren Abhängigkeiten für Sie beschäftigt es beißen Sie wirklich hart nicht zu weit nach unten die Linie.

IoC-Container sollten Ihnen ein API/Vokabular zur Verfügung stellen, um über die Systemarchitektur zu sprechen.

Die Injektion von Abhängigkeiten führt dazu, dass Sie kleinere entkoppelte Klassen verwenden, die als Bausteine für Teilsysteme dienen. Das ist gut, denn so können Sie Ihre Bausteine isoliert testen und leichter über sie nachdenken. (Man kann sie sich wie elektronische Komponenten in einer Schaltung vorstellen)

IoC-Container sollten Ihnen eine Möglichkeit bieten, die Zusammensetzung dieser Bausteine klar auszudrücken. (das Verdrahtungsschema, das die Komponenten miteinander verbindet)

Mit dieser Trennung können Sie auch anfangen, über die Lebensdauer Ihrer Subsysteme nachzudenken: wann Sie Fabriken und Register verwenden, wie Sie Nachrichten im System weitergeben, ohne Kopplung einzuführen usw.

Der Sinn des IOC ist es, Ihnen einen Ort zu geben, an dem Sie all diese Logik explizit darlegen können, und nicht, sie auf magische Weise für Sie zu lösen.

Ich hoffe, das hilft.

Answer 3

Martin Fowler hat diesen Artikel geschrieben, der so etwas wie eine Bibel für die Inversion der Kontrolle und die Injektion von Abhängigkeiten ist. Er erklärt, wie man einen IoC-Container implementiert, und erörtert die Vorzüge verschiedener Injektionsmechanismen. http://martinfowler.com/articles/injection.html

Ganz gleich, welche Sprache Sie verwenden, das "Aneinanderreihen von Abhängigkeiten" ist nicht skalierbar. Es wird schwierig zu warten sein, weil andere Entwickler wahrscheinlich nicht wissen, wo all die Handstrings stattfinden, so dass sie, wenn sie etwas ändern, möglicherweise nicht das Richtige ändern. Wenn man dagegen alles an einer Stelle zusammenfasst, lassen sich künftige Änderungen viel leichter umsetzen. IoC hilft dabei, sich wiederholenden Code zu minimieren und eine Trennung der Belange und eine konsistente Anwendungsarchitektur zu gewährleisten.

Andererseits klingt es so, als hätten Sie eine ziemlich gut funktionierende Anwendung - und wenn Sie nicht gerade viel Zeit haben, ist es vielleicht nicht nötig, sie zu reparieren, wenn sie nicht kaputt ist.

Answer 4

Wenn Sie kein überdimensioniertes DIC haben wollen, sondern eines, das alles, was Sie brauchen, auf sehr kompakte Weise liefert, sollten Sie dieses ausprobieren: Bucket ( https://github.com/troelskn/bucket ). Mehr braucht ein DI-Container nicht. Neben Symfony's einer ist oft in einer sehr gefährlichen Weise verwendet, als Service-Locator (die schönere alias globalen Zustand).

Answer 5

Wenn Sie denken, dass Ihr IoC leichtgewichtiger ist/ sein kann als das, was andere Frameworks bereits haben, und wenn Sie genug Zeit haben, es zu entwickeln, dann bauen Sie Ihr eigenes. Ich persönlich benutze IoC in meinem MVC-Framework nur für die Verknüpfung der View mit dem Controller. Ich verwalte den View und seine Parameter über eine Registry (ein standardisiertes, assoziatives Array), die Modelle werden als externe Dienste behandelt. Ich habe IoC und DI auch zum ersten Mal in Java entdeckt, also habe ich versucht, das Beste aus beiden Sprachen (Java und PHP) zu nehmen, als ich mein Framework gebaut habe.Natürlich verbindet es nichts mit irgendetwas, aber das brauche ich in meinem Fall nicht, also brauchen Sie es vielleicht auch nicht.

IoC ist wichtig, um im Laufe der Zeit Flexibilität zu bieten, aber wie viel Flexibilität? Arbeiten Sie mit vielen externen Komponenten? Arbeiten Sie mit Standard-Plugins und Objekten? PHP ist nicht Java, Sie haben nicht diesen Sack voller Jars und Bibliotheken, die so gut entwickelt sind, dass Sie sie jederzeit implementieren können, indem Sie sie einfach laden und eine Direktive in einer XML-Datei ersetzen, um darauf zu verweisen, denken Sie darüber nach.

Ich habe eine hervorragende IoC-Implementierung auf einer außergewöhnlichen Open-Source-Software namens Alfresco (Document Management System) gefunden. Es ist ein Produkt, das JSF, Spring, Hibernate und Freemarker-Templates zusammenbringt, aber wie gesagt, es ist ein Produkt, das in Tausende von Geschäftsmodellen passen soll, es ist eher eine hochentwickelte Plattform, die endlos verändert werden soll, also muss sie hochflexibel sein.

Wenn Sie eine zielgerichtete Anwendung entwickeln, die nur ein Geschäftsmodell und einige wenige Kunden bedienen soll, dann wird das Eintauchen in IoC Blossom die Dinge eher erschweren als vereinfachen.

Einstein sagte, dass die Dinge einfach sein müssen, aber nicht einfacher als sie sind.