Ich suche Hilfe bei der Entscheidung, welches Dependency-Injection-Framework am besten zu unseren Anforderungen passt und ob dies überhaupt der richtige Weg ist oder nicht.

Aufstellen:

Ich arbeite mit einer Codebasis von ~300.000 Codezeilen. Wir haben eine Reihe von „Haupt“-Kunden sowie einen zusätzlichen Großkunden. Letzteres erforderte eine individuelle Version unserer Software, die wir dann zur Verfügung stellten.

Seitdem hat sich eine Kooperation mit weiteren Partnern in Aussicht gestellt. Einige von ihnen werden in Zukunft möglicherweise individualisierte Softwareversionen erfordern - dies kann von der reinen UI-Gestaltung bis hin zum Ausschluss großer Teile der Funktionalität reichen.

Daher streben wir derzeit an, unsere Codebasis zu modularisieren, vorzugsweise unter Verwendung von Dependency Injection (DI).

Die Codebasis ist in Java geschrieben, wir verwenden jedoch JNI und implementieren einen großen Teil der Funktionalität in C++. Dies sollte bei der Entscheidung über die Gerüsteignung berücksichtigt werden.

Derzeit zielen wir hauptsächlich darauf ab, Produktlinien, dh große Teile unserer Codebasis, zu modularisieren. In der Praxis wird es aber sehr wahrscheinlich auch eine Modularisierung von mittleren bis kleinen Features geben.

Untersuchung

Derzeit wird eine DI-Lösung favorisiert, ist aber keine Voraussetzung. Frameworks, die ich untersuche, sind hauptsächlich:

• Dolch 2
• Gestalt
• Frühling DI

Daneben gibt es noch weitere Lösungen, die zumindest kurz in Betracht gezogen werden:

• Koin
• Java-EE6-CDI
• Zahnstocher

Aspekte, die wir berücksichtigen:

• Modularisierungsfähigkeit
• Bemühung, Framework in einer großen Codebasis zu verwenden
• Leistung, insbesondere in Bezug auf die Speichernutzung
• Code-Verschleierung (Nicht oberste Priorität, es gab jedoch einige Vermutungen, ob einer unserer Kunden versucht hat, unseren Code zu dekompilieren, daher müssen wir dies ebenfalls berücksichtigen

Dolch 2

Bisher scheint dies der Favorit zu sein. Das Framework vermeidet die erwünschte Reflexion, insbesondere in Bezug auf die Speichernutzung, da dies eine Ressourcenbeschränkung für unsere Kunden darstellt.

Das Debuggen von Dagger 2 scheint einfacher zu sein als mit Spring und Guise, aufgrund der richtigen Rückverfolgbarkeit und ihres Fokus auf menschenlesbare Klassennamen.

Zu guter Letzt scheint es eine Möglichkeit zu geben, Code mit ProGuard zu verschleiern. Auch Boilerplate wird minimiert.

Ich betrachte jedoch die Lernkurve von Dagger 2, da einige behaupten, dass es ein hohes Maß an Komplexität haben kann. Es scheint auch @Overridenicht von Dagger 2 unterstützt zu werden, was zu mehr Refactoring führt, da solche Klassen in Module aufgeteilt werden müssen, wenn sie injiziert werden sollen.

Ein weiteres Problem besteht darin, Fehler nur zur Laufzeit zu finden, wenn bei der Injektion etwas schief geht. Dies kann dazu führen, dass Kunden auf Laufzeitfehler stoßen, die beim Staging unbemerkt geblieben sind.

Gestalt

Wie Spring DI hat Guise bereits eine große Community, etwas, das Dagger 2 möglicherweise noch fehlt, sodass das Finden von Antworten auf Fragen möglicherweise einfacher ist. Ein großer Vorteil gegenüber Spring DI ist das Verbinden von Klassen mithilfe von Typinformationen.

Guise verwendet jedoch, ebenso wie Spring DI, Reflexion, daher ist es in Bezug auf die Leistung nicht so gut. Für speicherbezogene Überlegungen ist dies ein Minus.

Dagger 2-Entwickler behaupten, einen Fokus auf bessere Debugging-Fähigkeiten gelegt zu haben, sie behaupten auch, dass mit Guise einige Breakpoints möglicherweise nicht einmal bei der Ausführung verstanden werden. Daher sind einige Anwendungen, die Guise verwenden, möglicherweise überhaupt nicht für Debugging-Zwecke geeignet.

Frühling DI

Das scheint der Oldtimer unter den Frameworks zu sein. Hinter Spring steht eine riesige Community, daher ist wahrscheinlich alles gut dokumentiert und Antworten sollten leicht online zu finden sein. Die Spring-Community scheint jedoch eher inaktiv zu sein, was bedeutet, dass zwar viele Antworten online verfügbar sind, aber neue schwer zu bekommen sind.

Framework verwendet XML, obwohl ich gelesen habe, dass es auch die Möglichkeit gibt, Anmerkungen zu verwenden. Beide Fälle sind Reflexionen, also wiederum nicht optimal, wenn man die RAM-Nutzung betrachtet.

Funktionen wie F3 von Eclipse sind nicht verfügbar, wenn es um injizierte Abhängigkeiten geht. Es gibt Spring IDE, dies wird jedoch überhaupt nicht als Option angesehen.

Spring DI enthält große Mengen an Boilerplate-Code, was bei unserer Codebasis von 300.000 Zeilen bemerkenswert ist.

Fragen

Vor allem würde ich gerne Ihre Meinung zu diesen Frameworks hören, ob Sie eines empfehlen oder nicht und ob Sie eines davon für die von mir beschriebene Aufgabe als geeignet erachten. Diese Dinge interessieren mich besonders:

• Sind diese Frameworks für die angestrebte Modularisierung geeignet?
• Ist der Leistungsunterschied so bemerkenswert, wie es scheint?
• Gibt es wichtige Faktoren, die ich bei der Entscheidung für ein Framework berücksichtigen sollte, die noch nicht erwähnt wurden? Vielleicht sieht der eine oder andere von euch typische Nöte im Umgang mit DI, die euch im Zusammenhang mit unserem Setup auffallen, die mir im Moment aber nicht auffallen.
• Bieten Spring DI oder Guise Code-Verschleierung an? Und lässt sich ProGuard so einfach einbinden, wie behauptet wird?
• Sollten andere Frameworks angesichts der beschriebenen Codebasis ernsthaft in Betracht gezogen werden?

Im Allgemeinen bin ich für jeden Einblick in dieses Thema dankbar, da ich kein Experte für DI bin. Wenn Sie in dieser Beschreibung irgendwelche roten Fahnen sehen, insbesondere eklatante Gründe dafür, warum eines der verfügbaren Frameworks in unserem Fall absolut keine gute Wahl ist, dann sind dies wertvolle Informationen.

Danke schön.