Teil 2. Lassen Sie uns ein wenig über Softwarearchitektur sprechen

Dieses Material ist Teil der Reihe „Einführung in die Unternehmensentwicklung“ . Der erste Teil zum Thema Networking finden Sie hier . Unter Softwarearchitektur versteht man die innerhalb einer Anwendung geschaffene Struktur, also die gesamten Module und Komponenten des Programms und deren Interaktion. Programmierer arbeiten schon sehr lange an guten Architekturen, daher ist es nicht verwunderlich, dass wir von vielen Architekturmustern gehört haben. Sie müssen sie verstehen: Beim Schreiben einer Webanwendung ist es entscheidend, eine gute Architektur zu entwickeln, da eine Webanwendung über mehr Komponenten und Module verfügt als eine normale Anwendung. Ein architektonisches Musterist eine clevere Möglichkeit, ein Software-Designproblem zu lösen. Sie sind wahrscheinlich schon auf Designmuster wie Factory-Methode, abstrakte Fabrik, Builder, Prototyp, Singleton und möglicherweise andere gestoßen. Wir verwenden sie, wenn wir Code schreiben, Klassen erstellen und planen, wie Klassen interagieren. Architekturmuster werden auf einer höheren Abstraktionsebene verwendet, wenn die Interaktion des Benutzers mit Servern, Daten und anderen Komponenten geplant wird. Werfen wir einen kurzen Blick auf einige Muster und deren Verwendung.

Client-Server-Architektur

Der Name erweckt den Eindruck, dass an diesem Muster alles einfach und klar ist. Aber lassen Sie uns einige Punkte klarstellen, damit Sie zu Beginn des Frühlingsstudiums verstehen, wovon wir sprechen. Nehmen wir an, Sie haben eine Chat-App geschrieben und beginnen gemeinsam mit einem Freund, sie zu nutzen. Sie könnten einen sehr einfachen Ansatz verfolgen und sich unter Verwendung bekannter IP-Adressen direkt über das Internet gegenseitig Nachrichten senden: Zunächst scheint alles gut zu funktionieren, bis ein anderer Ihrer Freunde Sie bittet, dem Chat beizutreten. Wenn Sie sich also entscheiden, Ihren gemeinsamen Freund zum Chat hinzuzufügen, stehen Sie vor einem architektonischen Problem: Für jeden Chat-Teilnehmer müssen Sie aktuelle Informationen über die Anzahl der Benutzer und die IP-Adresse neuer Benutzer bereitstellen. Und wenn eine Nachricht gesendet wird, muss sie allen Teilnehmern zugestellt werden. Dies sind die offensichtlichsten Probleme, die auftreten werden. Eine weitere Reihe von Problemen wird im Code selbst verborgen sein. Um sie zu vermeiden, müssen Sie einen Server verwenden, in dem alle Informationen über Benutzer, einschließlich ihrer Adressen, gespeichert werden. Nachrichten müssen nur an den Server gesendet werden. Es sendet wiederum Nachrichten an jeden Empfänger. Wenn Sie sich entscheiden, Ihrer Chat-App einen Serverteil hinzuzufügen, beginnen Sie mit dem Aufbau einer Client-Server-Architektur.

Komponenten der Client-Server-Architektur

Mal sehen, worum es geht. Eine Client-Server-Architektur ist ein Entwurfsmuster, das zum Erstellen von Webanwendungen verwendet wird. Diese Architektur besteht aus drei Komponenten:

1. Client – ​​Anhand des Namens können wir erkennen, dass diese Komponente einen Dienst (die Webanwendung) nutzt und einen Server kontaktiert, um Informationen anzufordern.

2. Server – Hier befindet sich Ihre Webanwendung oder der Serverteil davon. Es speichert die notwendigen Benutzerinformationen oder kann diese anfordern. Wenn ein Client eine Anfrage sendet, ist es außerdem der Server, der die angeforderten Informationen zurückgibt.

3. Netzwerk – Dieser Teil ist einfach. Es erleichtert den Informationsaustausch zwischen Client und Server.

Der Server kann eine große Anzahl von Anfragen verschiedener Benutzer verarbeiten. Das bedeutet, dass es viele Clients geben kann. Wenn sie untereinander Informationen austauschen müssen, muss dies über den Server geschehen. Somit hat der Server eine weitere Funktion: die Verkehrskontrolle. Was unser Multi-User-Chat-Programm betrifft, besteht die gesamte Anwendung aus zwei Modulen:

• ein Client-Modul – enthält eine grafische Oberfläche zum Anmelden und Senden/Empfangen von Nachrichten

• ein Servermodul – eine Webanwendung, die auf einem Server gehostet wird und Nachrichten von Benutzern empfängt, verarbeitet und dann an Empfänger sendet

Wenn wir im Internet nach nützlichen (oder nicht sehr nützlichen) Informationen suchen möchten, öffnen wir einen Browser, geben eine Suchanfrage in die Suchleiste ein und erhalten als Antwort Informationen von der Suchmaschine. In dieser Kette ist der Browser der Client. Es sendet eine Anfrage mit Informationen darüber, wonach wir suchen, an den Server. Der Server verarbeitet die Anfrage, findet die relevantesten Ergebnisse, packt sie in ein Format, das der Browser (Client) verstehen kann, und sendet sie zurück. Komplexe Dienste wie Suchmaschinen können viele Server haben. Zum Beispiel ein Autorisierungsserver, ein Server zum Suchen von Informationen, ein Server zum Generieren der Antwort usw. Der Client ist sich dessen jedoch nicht bewusst und kümmert sich nicht darum: Für den Client ist der Server eine einheitliche Einheit. Der Client kennt nur den Einstiegspunkt, d. h. die Adresse des Servers, an den Anfragen gesendet werden sollen. Erinnern Sie sich an den Antrag, den wir geprüft habender vorherige Teil dieser Serie . Es diente dazu, die durchschnittliche Lufttemperatur in allen Ländern in Echtzeit zu überwachen. Seine Architektur sieht in etwa so aus: Unsere Anwendung liegt auf dem Server. Nehmen wir an, dass es alle fünf Sekunden Anfragen an Server sendet, die von lokalen Wetterstationen betrieben werden, von den Servern Temperaturinformationen für ein bestimmtes Land empfängt und diese Informationen speichert. Wenn der Kunde uns auffordert, „die aktuelle Lufttemperatur der Welt anzuzeigen“, geben wir die zuletzt gespeicherten Informationen zurück, sortiert nach Land. Somit fungiert unsere Anwendung sowohl als Server (wenn sie Benutzeranfragen verarbeitet) als auch als Client (wenn sie Informationen von anderen Servern empfängt). Eine einfache Client-Server-Architektur wird sehr selten und nur für sehr einfache Anwendungen verwendet. Für wirklich große und komplexe Projekte nutzen wir unterschiedliche Architekturen, die Ihnen in Zukunft begegnen werden. Schauen wir uns nun ein Modell an, das der Client-Server-Architektur sehr ähnlich ist.

Dreistufige Architektur

Dies ist ein Architekturmuster, das ein drittes Modul einführt – die Datenspeicherung . In diesem Muster werden die drei Ebenen üblicherweise als Schichten oder Ebenen bezeichnet:

1. Die Client-Schicht ist die Benutzeroberfläche, auch Präsentationsschicht genannt. Dabei kann es sich um einen Webbrowser handeln, der HTML-Seiten empfängt, oder um eine mit JavaFX geschriebene grafische Benutzeroberfläche. Die Hauptsache ist, dass diese Schicht es dem Benutzer ermöglicht, Anfragen an den Server zu senden und seine Antworten zu verarbeiten.

2. Die Logikschicht ist der Server, der Anfragen/Antworten verarbeitet. Oft wird sie auch als Serverschicht bezeichnet. Hier finden auch alle logischen Operationen statt: mathematische Berechnungen, Datenoperationen, Aufrufe anderer Dienste oder Datenspeicher usw.

3. Die Datenschicht ist der Datenbankserver: Unser Server interagiert mit ihm. Diese Schicht speichert alle Informationen, die für den Betrieb der Anwendung erforderlich sind.

Somit übernimmt unser Server die volle Verantwortung für den Zugriff auf die Daten und ermöglicht dem Benutzer keinen direkten Zugriff darauf.

Vorteile einer dreistufigen Architektur

Eine solche Architektur bietet uns viele Vorteile, darunter:

1. Die Fähigkeit zum Schutz vor SQL-Injection (dies ist ein Angriff auf einen Server; dabei geht es um das Senden von SQL-Code, der es einem Angreifer bei seiner Ausführung ermöglicht, auf unsere Datenbank einzuwirken).

2. Trennung der Daten, auf die wir den Benutzerzugriff kontrollieren möchten.

3. Die Möglichkeit, Daten zu ändern, bevor sie an den Client gesendet werden.

4. Skalierbarkeit (die Möglichkeit, unsere Anwendung auf mehrere Server zu erweitern, die dieselbe Datenbank verwenden).

5. Weniger strenge Anforderungen an die Qualität der Benutzerverbindungen. Wenn wir eine Antwort auf dem Server generieren, holen wir uns oft viele verschiedene Informationen aus einer Datenbank und formatieren sie, sodass nur das übrig bleibt, was der Benutzer benötigt. Dadurch wird die Menge an Informationen reduziert, die wir in unserer Antwort an den Kunden senden.

Wie oft sollten Architekturmuster verwendet werden?

Wenn Sie beispielsweise mit dem Designmuster der Factory-Methode vertraut sind, haben Sie sich wahrscheinlich gefragt, wann Sie es verwenden sollten. Manchmal ist es schwer zu entscheiden, was zu tun ist: ein Objekt mit dem neuen Operator oder einer Factory-Methode erstellen. Aber mit der Zeit stellt sich das Verständnis ein. Bei architektonischen Mustern sieht es kaum anders aus. Enterprise-Frameworks sollen es einem Programmierer ermöglichen, ein Projekt basierend auf einem allgemein akzeptierten Muster zu erstellen. Dementsprechend sollten Sie vor dem Erlernen des Spring Frameworks unbedingt die Client-Server-Architektur, die dreistufige Architektur und die MVC-Architektur verstehen. Keine Sorge: Wir werden noch über die MVC-Architektur sprechen. Teil 3. HTTP/HTTPS Teil 4. Die Grundlagen von Maven Teil 5. Servlets und die Java-Servlet-API. Schreiben einer einfachen Webanwendung Teil 6. Servlet-Container Teil 7. Einführung in das MVC-Muster (Model-View-Controller).