Читать книгу Spring Boot - Mark Heckler - Страница 9

Einer der genialen Aspekte von Spring Boot besteht darin, dass es das Dependency- oder Abhängigkeitsmanagement handhabbar macht.

Falls Sie bereits einmal ernsthaft Software entwickelt haben, mussten Sie sich bestimmt schon mehrfach den Kopf hinsichtlich des Abhängigkeitsmanagements zerbrechen. Jede Fähigkeit, die Sie mit Ihrer Anwendung anbieten, erfordert im Vorfeld üblicherweise eine Reihe von Abhängigkeiten. Falls Sie zum Beispiel ein RESTful-Web-API bereitstellen, müssen Sie eine Möglichkeit zur Verfügung stellen, Endpoints über HTTP anzubieten, auf Anfragen (Requests) zu lauschen, diese Endpoints an Methoden/Funktionen zu binden, die diese Anfragen verarbeiten, um dann passende Antworten (Responses) zu erzeugen und zurückzuliefern.

Jede primäre Abhängigkeit zieht fast zwangsläufig zahllose weitere sekundäre Abhängigkeiten nach sich, um ihre versprochene Funktionalität zu erfüllen. Um bei unserem Beispiel eines RESTful-API zu bleiben: Wir können eine Reihe von Abhängigkeiten erwarten (in einer vernünftigen, wenn auch strittigen Struktur), die Code enthalten, der Responses in einem bestimmten Format liefert, z.B. JSON, XML, HTML, Code zum Marshalling/Demarshalling von Objekten in bestimmte Formate, Code zum Lauschen auf und Verarbeiten von Anfragen und zum Zurückgeben von Antworten auf diese, Code zum Decodieren komplexer URIs, die benutzt werden, um vielseitige APIs zu erzeugen, Code zum Unterstützen verschiedener Übertragungsprotokolle und mehr.

Selbst für dieses relativ einfache Beispiel müssen wir wahrscheinlich schon mit einer großen Anzahl von Abhängigkeiten in unserer Build-Datei rechnen. Und wir haben an dieser Stelle noch gar nicht darüber nachgedacht, welche Art Funktionalität wir in unsere Anwendung aufnehmen wollen, sondern nur ihre nach außen gerichteten Interaktionen betrachtet.

Reden wir nun über Versionen und über jeder einzelne dieser Abhängigkeiten.

Die gemeinsame Benutzung von Bibliotheken erfordert eine gewisse Präzision, da es sein kann, dass eine Version einer speziellen Abhängigkeit nur mit einer bestimmten Version einer anderen Abhängigkeit getestet wurde (oder gar nur mit ihr korrekt funktioniert). Solche Probleme, die unweigerlich auftauchen, bezeichne ich als »Abhängigkeits-Whack-a-Mole« (»Hau den Maulwurf«).

Genau wie das namengebende Spiel kann auch Abhängigkeits-Whack-a-Mole sehr frustrierend sein. Anders als bei dem Spiel gibt es jedoch keine Preise zu gewinnen, wenn man Bugs, die aus falschen Zuordnungen resultieren, jagt und zerhaut, sondern höchstens seltsame Diagnosen und Stunden, die man mit der Suche nach ihnen verplempert hat.

Doch jetzt kommen Spring Boot und seine Starter. Spring-Boot-Starter sind Bills of Materials (BOMs; also quasi Stücklisten), die aufgrund der erwiesenen Tatsache erstellt werden, dass Sie eine bestimmte Funktion in der Mehrzahl der Fälle auf nahezu dieselbe Weise bereitstellen.

Jedes Mal, wenn wir im oben angeführten Beispiel ein API bauen, stellen wir Endpoints bereit, lauschen auf Anfragen, verarbeiten die Anfragen, wandeln Objekte um, tauschen Informationen in verschiedenen Standardformaten aus, senden und empfangen Daten mit einem bestimmten Protokoll über die Leitung und mehr. Dieses Muster aus Entwurf/Entwicklung/Benutzung ändert sich nicht sehr, sondern ist ein branchenübliches Vorgehen, das so oder so ähnlich verwendet wird. Und wie andere vergleichbare Muster lässt es sich sehr schön in einem Spring-Boot-Starter festhalten.

Das Hinzufügen eines einzigen Starters, z.B. spring-boot-starter-web, fasst alle dazugehörigen Funktionalitäten in einer einzigen Anwendungsabhängigkeit zusammen. Alle Abhängigkeiten, die in diesem einen Starter enthalten sind, sind darüber hinaus versionssynchronisiert. Das heißt, sie wurden erfolgreich zusammen getestet, und die enthaltene Version von Bibliothek A funktioniert einwandfrei mit der enthaltenen Version von Bibliothek B … und C … und D und so weiter. Dadurch wird unsere Liste mit den Abhängigkeiten und damit unser Leben drastisch vereinfacht, da es ziemlich unwahrscheinlich wird, dass schwer zu identifizierende Versionskonflikte zwischen Abhängigkeiten auftreten, die Sie für die wichtigen Funktionen Ihrer Anwendung zur Verfügung stellen müssen.

In den seltenen Fällen, in denen Sie Funktionalität einbauen müssen, die von einer anderen Version einer enthaltenen Abhängigkeit bereitgestellt wird, können Sie die getestete Version einfach übergehen.

Falls Sie sich über die vorgegebene Version einer Abhängigkeit hinwegsetzen müssen, dann tun Sie das … allerdings sollten Sie dann wahrscheinlich Ihre Tests ausweiten, um die Risiken auszuschalten, die Sie sich durch Ihr Vorgehen möglicherweise einhandeln.

Sie können Abhängigkeiten, die für Ihre Anwendung unnötig sind, auch ausschließen. Dabei gelten allerdings dieselben Vorsichtsmaßnahmen.

Alles in allem rationalisiert das Starter-Konzept von Spring Boot Ihre Abhängigkeiten und verringert den Aufwand, der nötig ist, um ganze Gruppen von Fertigkeiten in Ihre Anwendungen einzubauen. Es verringert außerdem den für Tests, Wartung und Aktualisierung anfallenden Overhead.