Spring Boot: Vom Hype zur etablierten Basistechnologie?
Dependency Injection, einer der wesentlichen Bestandteile von Spring, lässt sich auch mit alternativen Frameworks oder in Eigenregie erledigen. Warum also Spring einsetzen? Entwicklerproduktivität lautet die Antwort.
(Bild: Pixabay)
- Michael Simons
Zu den Kernaufgaben des Spring Framework gehört es seit jeher, Dependency Injection (DI) bereitzustellen. Spring Boot hilft darüber hinaus, Abhängigkeiten zu verwalten, Dinge zu konfigurieren und vieles andere mehr – es ist aber nur Mittel zum Zweck. Kein Entwicklerprojekt benötigt daher zwingend Spring. Denn die reine Dependency Injection lässt sich mit wenig Aufwand selbst entwickeln. Alternativ kann eines der vielen kleinen Frameworks zum Einsatz kommen. Reine Web-Frameworks, mit denen sich schnell Services entwickeln lassen und HTTP-Endpunkte bereitstellen, bieten sich dafür beispielsweise an. Zu den neueren Vertretern dieser Klasse zählt etwa das "container-freie" Micronaut, das keinen Servlet-Container nutzt, sondern IO nicht blockierend auf Basis von Netty abhandelt.
Unter den Argumenten, die für Spring und insbesondere Spring Boot sprechen, steht an erster Stelle die Entwicklerproduktivität. Eine neue Anwendung auf Basis von Spring sollte immer mit Spring Boot aufgesetzt werden, solange nicht gravierende Gründe dagegensprechen. Das Ergebnis ist ein Anwendungsskelett, das immer gleich aussieht und sich ähnlich konfigurieren lässt. Standardaufgaben wie die Konfiguration einer Datenbankverbindung, unabhängig davon, ob zu einer relationalen oder einer Graphdatenbank, lassen sich gleichermaßen durchführen. Das gilt ebenso für die Integrationen von Anwendungen zu anderen Diensten: als Abhängigkeit in Form eines Starters deklariert und ohne Codegenerierung vom Autokonfigurationsmechanismus von Spring Boot konfiguriert.
Externe Konfiguration ist ein weiteres wichtiges Produktivitätsfeature: Passen Standardwerte nicht, lassen sie sich in der Regel extern anpassen. Dazu dienen Dateien im Properties- oder YAML-Format, Umgebungsvariablen, Kommandozeilenparameter und ähnliche Mechanismen. Neben Aspekten wie plattformeinheitlichem Handling von Transaktionen und Caches, dem Testframework, einem Framework-internen Event-System und spannenden Projekten wie Spring Data und Integration sind die Mechanismen gute Gründe für Spring.
Im Gespräch: Michael Simons über Spring Boot 2 und sein neues Buch
Im heise Developer-Blog Neuigkeiten von der Insel sprach Michael Simons mit Thorben Janssen nicht nur über Spring Boot und sein neues Buch "Spring Boot 2 – Moderne Softwareentwicklung mit Spring 5", sondern verriet auch ein wenig Privates.
Dependency Injection spielt nach Ansicht des Autors im Vergleich dazu nur eine untergeordnete Rolle. Allerdings bleibt DI immer noch wichtiger als die vollautomatische Suche nach Spring Beans (das sind Klassen, die als Instanzen im Spring-Kontext existieren) auf Basis von Annotationen (@Component, @Service etc.).
Spring Boot – ein Framework zum Steuern von Frameworks?
Das Spring-Jira-Ticket SPR-9888 (Improved support for 'containerless' web application architectures) aus dem Jahr 2012 – Mitte 2013 als "won’t fix" geschlossen – beschreibt sehr detailliert etliche der Kernideen, die heute als selbstverständlich gelten. Die Bedeutung von Developer- und auch Operations-Produktivität zeichnete sich bereits konkret ab. Die Enterprise-Welt war bereits zu diesem Zeitpunkt einem drastischen Wandel unterworfen, Wissen um die Eigenarten von Servlet-Containern nicht mehr voraussetzbar. Die Vielzahl von Abhängigkeiten von Spring, entweder durch intrinsische Notwendigkeit oder auf Grund vorhandenen Supports von Bibliotheken, hoben die Lernkurve von Spring drastisch an. Konfiguration war oftmals abhängig vom Container.
Projekte wie Spring Roo mit dem Code-Generierungsansatz schafften es nicht aus der Nische. Die meisten Projekte und Projektteams schufen eigene Konfigurationsvarianten, die erfahrene Spring-Entwickler schnell verstanden. Oft litten sie aber unter Inkompatibilität zueinander und trugen eher zum Cargo Cult bei.
Abhilfe versprach ein einheitliches Komponentenmodell mit interner (automatische Konfiguration, die unter anderem nach An- oder Abwesenheit von Klassen entscheidet, wie Dinge genutzt werden) wie auch externer Konfiguration sowie das in sich abgeschlossene Deployment-Konzept eines self-contained-jar.
