WikiDer > Frühlings-Framework

Spring Framework
Frühlings-Framework
EntwicklerVMware
Letzte Version5.2.5 
(24. März 2020)
StatusAktiv
BetriebssystemMultiplattform
Geschrieben inJava
KategorieRahmen
LizenzApache-Lizenz 2.0
Versionskontrollegithub.com
Webseite(und) Projektseite
Portal  Portalsymbol  Informatik
Java-Plattform

Frühlings-Framework, normalerweise abgekürzt mit springen, ist ein kostenlosRahmen konzentriert sich auf die Entwicklung Software in dem Programmiersprache Java. Es Rahmen kombiniert APIs und Ideen, die es zu einer Alternative zur Standardentwicklung machen. Dank verschiedener Erweiterungen wird es hauptsächlich als Alternative oder Erweiterung zu Technologien von J2EE-Plattform. Version 3.1, veröffentlicht am 13. Dezember 2011, brachte Unterstützung für Java 7. Spring Framework Version 4 unterstützt Java 6, 7 und 8.

Geschichte

Die erste Version wurde entwickelt von Rod Johnson und erschien bei der Veröffentlichung seines Buches "Expert One-on-One J2EE Design and Development"[1] im 2002. Das Framework wurde erstmals im Jahr 2003 veröffentlicht, unter der Apache-Lizenz.

J2EE

Die normale Arbeitsweise

Es J2EEPlattform zielt auf die Entwicklung komplexer Anwendungen, hauptsächlich für den gewerblichen Markt. Die Architekturidee dieser Plattform besteht darin, dass Anwendungen nach einer funktionalen Gliederung in mehrere Schichten (Stufen genannt) und dass jede Schicht durch eine Reihe von Komponenten implementiert wird. Jede Schicht hat ihren eigenen Komponententyp: a Servlet oder EJB. Diese dienen dazu, Business-Funktionalität zusammen mit einer technischen Infrastruktur anzubieten, die sicherstellt, dass andere Anwendungen und Benutzer auf die Funktionalität jeder Komponente zugreifen können.

Die technische Architektur besteht aus einer Sammlung technischer "Dienste": Zugriff auf Datenbanken, Kommunikationsmechanismen und Transaktionsmechanismen. Der Dienst wird dem Geschäftsteil einer Komponente über eine als "Container" bezeichnete Standardeinrichtung bereitgestellt. Dieser Container akzeptiert als Eingabe ein Stück Software von a Programmierer die Implementierung der Business-Funktionalität enthalten und dann mit Zugriff auf die technische Infrastruktur versehen.

Die J2EE-Plattform, zusätzlich zu den APIund anderen Einrichtungen, eine Sammlung von Vereinbarungen darüber, wie die technische Infrastruktur von der Geschäftsfunktionalität aus angesprochen und betrieben werden soll. Darüber hinaus gibt es Vereinbarungen darüber, wie die Business-Funktionalität an den Container angebunden werden soll.

Mit diesen Vereinbarungen ist es grundsätzlich möglich, die Business-Funktionalität so zu schreiben, dass sie ohne Änderung in jede Container-Implementierung implementiert werden kann und transparent auf die spezifischen Möglichkeiten dieses Containers zugreifen kann (die Business-Funktionalität weiß, dass es Datenbank mit einem bestimmten Satz von Tabellen, aber die Details (wie der Datenbanktyp) sind unbekannt - das steuert den Container). Darüber hinaus kann auch andere Software die Business-Funktionalität transparent nutzen – sie wird standardmäßig innerhalb des Systems bereitgestellt („veröffentlicht“) und ist somit standardmäßig zugänglich.

Kritik

An obigem System gibt es einiges zu kritisieren. Es wurden ganze Bücher der Kritik veröffentlicht, insbesondere im Bereich der Komplexität und Grenzen des Systems.

  • Business-Funktionalität in einen Container zu bekommen ist zu kompliziert: Um transparent entwickeln zu können, ist J2EE stark auf Konfiguration durch XMLDateien. Diese Dateien, auch "Bereitstellungsdeskriptoren" genannt, sind oft komplex, da sie viele Informationen enthalten.
  • EJBs sind komplex und schwer: Die EJB-Entwicklung geht weit über die reine Definition von Geschäftsfunktionen hinaus. Damit ein EJB ordnungsgemäß mit dem Container verbunden werden kann, muss ein EJB mit mehreren Extras ausgestattet sein – nicht nur einem Deployment-Deskriptor, sondern auch mindestens zwei Schnittstellen, die mit dem EJB bei Änderungen synchron gehalten werden müssen. Für bestimmte Typen von EJBs werden zusätzliche Schnittstellen und Hilfeklassen hinzugefügt.
  • EJBs werden aufgrund der Art und Weise, wie der Container sie handhabt, häufig verwendet: Der Container fügt alle möglichen nützlichen Funktionen hinzu, aber diese Funktionalität verbraucht Speicher und Prozessorzeit. Für den Service verbraucht es auch Netzwerkbandbreite und Datenbankzeit. Letztere können so extreme Formen annehmen, dass es fraglich ist, ob EJBs, die seinerzeit zum einfachen Aufbau sicherer Datenbankzugriffe und Dienste entwickelt wurden, geeignet sind, um stark datenbankorientierte Anwendungen zu entwickeln.
  • Die Standardmethode zum Veröffentlichen von Diensten ist nett – hat jedoch den Effekt, dass die Verwendung von Diensten den Code an eine einzelne Installation bindet und außerdem dazu führt, dass die Anforderungen für Dienste über den Code verteilt werden.
Um Dienste nutzen zu können, muss der Zugang zu diesen Diensten immer namentlich beantragt werden. Dies ist eine sich wiederholende Angelegenheit, die es auch erforderlich machen kann, die Software, die Dienste verwendet, an eine bestimmte Containerimplementierung und -installation festzunageln. Transparenz endet außerhalb des Containers; Eine Software von außerhalb des Containers, die die Dienste innerhalb des Containers nutzen möchte, muss alles mit Namen und spezifischer Adresse anfordern.

Frühling: alles anders herum

Inversion of Control (oder Dependency Injection)

Die Grundidee von Spring ist, dass ein Container (ein Ding, das eine technische Infrastruktur für ein Bündel von Geschäftsfunktionen bereitstellt) eine gute Idee ist, aber dieser Container sollte in keiner Weise Anforderungen an die Implementierung der Geschäftsfunktionalität stellen. Die Business-Funktionalität muss daher mit klassischen Java-Objekte (Englisch: Einfaches altes Java-Objekt, abgekürzt POJO) und dass diese Objekte auch nichts anderes tun, als diese Funktionalität zu implementieren. Ein POJO sollte nicht gezwungen werden, irgendeine Form anzunehmen, um mit dem Container zu interagieren, sollte keine zusätzlichen Schnittstellen oder Hilfsklassen zugunsten des Containers benötigen, noch sollte es eine lange Konfigurationsdatei mit allen möglichen Macken erfordern, die nur für . gelten eine bestimmte Art von Komponenten.

Durch Umkehrung der Kontrolle oder Abhängigkeitsspritze jede Komponente und Implementierung von Geschäftsfunktionen wird als einfaches JavaBean angesehen. Ein einfaches JavaBean weiß (im Grunde) nichts über den Rest des Systems: Es ist eine einfache Klasse in Java, kombiniert mit Methoden zum Anfordern von Informationen ("Getter") und Eingeben von Informationen ("Settern"). Das Verhalten dieser Beans hängt von anderen Beans ab, benötigt jedoch einen Setter oder Konstruktor, um eine andere Bean eingeben zu können (Beans importieren weder selbst andere Beans noch instanziieren sie die Beans selbst). Benötigte Beans werden von einer externen Entität (Container) bereitgestellt.

Der Spring-Container ist das System, das sicherstellt, dass eine Bohne mit allen notwendigen Einrichtungen ausgestattet ist, damit diese Bohne funktioniert. Wenn eine Bohne eine andere Bohne braucht, weiß der Spring-Container

  • welche Bohne wird benötigt
  • wo es gebraucht wird
  • mit welchem ​​Setter diese Bohne gefüttert werden soll.

Der Spring-Container instanziiert alle Bohnen, die benötigt werden, wenn sie gebraucht werden und versorgt sie wiederum mit allen benötigten Bohnen. Das ist Abhängigkeitsspritze: Was eine Bohne braucht, wird durch den Spring-Container in diese Bohne injiziert. Dies ist ein wesentlicher Unterschied zur EJB-Methode, bei der jede Komponente selbst nach allem suchen muss, was sie braucht. Dieses Prinzip ermöglicht es auch, Komponenten zu entwerfen und zu bauen, die wirklich praktisch alle Geschäftsfunktionen enthalten – eine Infrastruktur oder ein anderer Dienst, der für eine solche Komponente verwendet werden soll, ist nur die Eingabe einer Variablen in ein Objekt das Objekt eingetragen. Das eigentliche Suchen, Erstellen und andere schwierige Dinge werden vom Spring-Container erledigt und die Komponente (das POJO) muss nichts anderes wissen (nicht einmal, dass es einen Spring-Container gibt).

Der Spring-Container wiederum wird von einer Konfigurationsdatei gespeist, die eine Liste aller Beans im System enthält und welche weiteren Beans für jedes Bean benötigt werden. Darüber hinaus gibt es pro Bean zusätzliche Konfigurationsmöglichkeiten, die hauptsächlich auf das Setzen von Anfangswerten für die Bean beim Anlegen hinauslaufen.

Dies bedeutet, dass Spring seine eigenen Prinzipien verletzen muss: Eine Bean muss für die Dependency Injection ein wenig umgeformt werden (eine zusätzliche Variable und ein Setter oder ein Parameter im Konstruktor) und eine Konfigurationsdatei bleibt. Diese Konfigurationsdatei ist viel einfacher als die J2EE-Abhängigkeitsdeskriptoren: Das Formular ist viel einfacher und eindeutiger und es können weit weniger Konfigurationsarten vorgenommen werden. Dies folgt auch direkt aus der Tatsache, dass für den Spring-Container alles eine Spring-Bean und damit tatsächlich ein POJO ist: Wenn man als Container nichts weiter weiß, als dass etwas ein Bean ist und man einige Setter erwarten kann, kann man keine Eingabe konfigurieren für alles andere als Setter auf einem POJO.

Aspektorientierte Programmierung

Es ist praktisch unmöglich, eine Geschäftsanwendung zu schreiben, die nur aus Geschäftsfunktionen besteht. Eine moderne Geschäftsanwendung bietet auch andere Funktionen – zum Beispiel Sicherheit oder andere Regeln für die Anwendung der Geschäftsfunktionalität. Allerlei Dinge, die rund um die Business-Funktionalität passieren, sich oft wiederholen, sind anwendungsspezifisch (und können daher nicht im Container verarbeitet werden) und müssen in der Anwendung zwischen Container und Beans liegen.

Eine solche Funktionalität erfordert tatsächlich eine Art Code zu schreiben, der an verschiedenen, spezifischen Stellen im Programm aufgerufen werden kann – um oder in der Mitte der Geschäftsfunktionalität. Aber natürlich ohne dies in die Umsetzung der Business-Funktionalität einzubeziehen, da es sonst mit technischen Details verseucht wird.

Der Frühling bietet eine (Grund-)Vorsorge für aspektorientierte Programmierung damit Programme an bestimmten Stellen durch fremden Code "unterbrochen" werden können. Dieser Code tut etwas, ändert möglicherweise den Status des Programms oder seine Ausführung und führt das Programm dann weiter aus, als ob nichts passiert wäre. Innerhalb von Spring ist es möglich, dass ein Programm im Spring-Container vor und nach jedem Methodenaufruf durch einen separaten Code unterbrochen wird. Dadurch ist es möglich, sich jederzeit um Dinge wie Sicherheit zu kümmern, ohne dass ein Stück Code mehrmals im Programm ausgeführt werden muss und auch ohne dass das Hauptprogramm "weiß, was los ist". Es ist möglich, den Programmablauf im unterbrechenden Code zu ändern, Argumente an unterbrochene Methoden anzupassen oder sogar die Methode komplett abzufangen und das Programm mit einer Fehlermeldung zu unterbrechen.

Model View Controller

Eine weitere Funktionalität, die Spring speziell auf der Webseite von . bietet Web Applikationen, ist ein Model View Controller-Struktur. Diese Einrichtung (eine Alternative zu Dingen wie Apache-Struts) ermöglicht es, die Darstellung von Informationen über eine Webseite und die Nutzung der Geschäftsfunktionen hinter dieser Webseite sauber zu trennen.

Weitere Funktionalität

Für Dinge wie Datenbankzugriff (Beharrlichkeit), Transaktionalität und dergleichen, haben die Macher von Spring gesagt: "Es gibt viele gute Implementierungen dieser Dinge, wir müssen das nicht durchgehen". Spring unterstützt den transparenten Zugriff und die Verwendung vieler anderer Frameworks und APIs, einschließlich Überwintern, iBATIS, JDO, JTA und JMS. Diese Unterstützung besteht in der Regel aus einer simulierten Bean über das jeweilige Framework oder API. Eine simulierte Bean ist eine Bean, die in die Spring-Konfiguration aufgenommen und durch Dependency Injection in andere Beans im Programm integriert werden kann.

Neben der Unterstützung separater Persistenz-Frameworks bietet Spring auch eine Schnittstelle zur direkten Datenbankkommunikation über die JDBC-API; Dies ist für Leute, die kein anderes Framework verwenden können oder wollen, aber einige der klassischen Nachteile von JDBC vermeiden möchten (einschließlich der großen Mengen an Fehlerbehandlungscode, der normalerweise für die JDBC-Kommunikation geschrieben werden muss). Diese Unterstützung ist jedoch normalerweise der Verwendung separater Persistenz-Frameworks nicht vorzuziehen und erfordert auch normalerweise mehr Codierung als externe Frameworks erfordern.