Key Concepts
Beachten Sie in Abbildung 1-2, dass jede der Schichten in der Architektur als geschlossen gekennzeichnet ist. Dies ist ein sehr wichtiges Konzept in der Schichtenarchitektur. Eine geschlossene Schicht bedeutet, dass eine Anfrage, die von einer Schicht zur nächsten wandert, die darunter liegende Schicht durchlaufen muss, um zur nächsten darunter liegenden Schicht zu gelangen. Zum Beispiel muss eine Anfrage, die von der Präsentationsschicht ausgeht, zuerst die Geschäftsschicht und dann die Persistenzschicht durchlaufen, bevor sie schließlich die Datenbankschicht erreicht.
Abbildung 1-2. Geschlossene Schichten und Anfragezugriff
Warum also sollte die Präsentationsschicht nicht direkt auf die Persistenzschicht oder die Datenbankschicht zugreifen können? Schließlich ist ein direkter Datenbankzugriff von der Präsentationsschicht aus viel schneller als der Weg durch eine Reihe unnötiger Schichten, nur um Datenbankinformationen abzurufen oder zu speichern. Die Antwort auf diese Frage liegt in einem Schlüsselkonzept, das als Isolationsebenen bekannt ist.
Das Konzept der Isolationsschichten bedeutet, dass Änderungen in einer Schicht der Architektur im Allgemeinen keine Auswirkungen auf Komponenten in anderen Schichten haben: Die Änderung ist auf die Komponenten innerhalb dieser Schicht und möglicherweise eine andere zugehörige Schicht (z. B. eine Persistenzschicht mit SQL) beschränkt. Wenn Sie der Präsentationsschicht einen direkten Zugriff auf die Persistenzschicht gestatten, würden sich Änderungen an SQL innerhalb der Persistenzschicht sowohl auf die Geschäftsschicht als auch auf die Präsentationsschicht auswirken, wodurch eine sehr eng gekoppelte Anwendung mit vielen Abhängigkeiten zwischen den Komponenten entsteht. Diese Art von Architektur ist dann sehr schwer und teuer zu ändern.
Das Konzept der Isolationsschichten bedeutet auch, dass jede Schicht unabhängig von den anderen Schichten ist und somit wenig oder gar keine Kenntnis von der inneren Funktionsweise anderer Schichten in der Architektur hat. Um die Macht und Bedeutung dieses Konzepts zu verstehen, betrachten Sie einen großen Refactoring-Aufwand, um das Präsentations-Framework von JSP (Java Server Pages) auf JSF (Java Server Faces) umzustellen. Unter der Annahme, dass die zwischen der Präsentationsschicht und der Geschäftsschicht verwendeten Verträge (z. B. das Modell) gleich bleiben, ist die Geschäftsschicht vom Refactoring nicht betroffen und bleibt völlig unabhängig von der Art des von der Präsentationsschicht verwendeten Benutzerschnittstellen-Frameworks.
Geschlossene Schichten erleichtern zwar die Isolierung von Schichten und tragen daher dazu bei, Änderungen innerhalb der Architektur zu isolieren, aber es gibt Zeiten, in denen es sinnvoll ist, dass bestimmte Schichten offen sind. Nehmen wir zum Beispiel an, Sie wollen eine Shared-Services-Schicht zu einer Architektur hinzufügen, die gemeinsame Dienstkomponenten enthält, auf die von Komponenten innerhalb der Geschäftsschicht zugegriffen wird (z. B. Daten- und String-Utility-Klassen oder Auditing- und Protokollierungsklassen). Die Erstellung einer Diensteschicht ist in diesem Fall in der Regel eine gute Idee, da sie den Zugriff auf die gemeinsamen Dienste architektonisch auf die Geschäftsschicht (und nicht auf die Präsentationsschicht) beschränkt. Ohne eine separate Schicht gibt es architektonisch nichts, was den Zugriff der Präsentationsschicht auf diese gemeinsamen Dienste einschränkt, was es schwierig macht, diese Zugriffsbeschränkung zu regeln.
In diesem Beispiel würde die neue Diensteschicht wahrscheinlich unterhalb der Geschäftsschicht liegen, um anzuzeigen, dass die Komponenten in dieser Diensteschicht nicht von der Präsentationsschicht aus zugänglich sind. Dies stellt jedoch insofern ein Problem dar, als die Geschäftsschicht nun durch die Diensteschicht gehen muss, um zur Persistenzschicht zu gelangen, was überhaupt keinen Sinn macht. Dies ist ein uraltes Problem der Schichtenarchitektur, das durch die Schaffung offener Schichten innerhalb der Architektur gelöst wird.
Wie in Abbildung 1-3 dargestellt, ist die Dienste-Schicht in diesem Fall als offen markiert, was bedeutet, dass Anfragen diese offene Schicht umgehen und direkt zur darunter liegenden Schicht gehen dürfen. Im folgenden Beispiel darf die Geschäftsschicht, da die Dienste-Schicht offen ist, diese nun umgehen und direkt zur Persistenz-Schicht gehen, was durchaus sinnvoll ist.
Abbildung 1-3. Offene Schichten und Anforderungsfluss
Die Verwendung des Konzepts offener und geschlossener Schichten hilft, die Beziehung zwischen Architekturschichten und Anforderungsflüssen zu definieren, und liefert Designern und Entwicklern die notwendigen Informationen, um die verschiedenen Zugriffsbeschränkungen der Schichten innerhalb der Architektur zu verstehen. Wird nicht dokumentiert oder richtig kommuniziert, welche Schichten in der Architektur offen und geschlossen sind (und warum), führt dies in der Regel zu eng gekoppelten und brüchigen Architekturen, die sehr schwer zu testen, zu warten und einzusetzen sind.