Key Concepts
Zauważ na rysunku 1-2, że każda z warstw w architekturze jest oznaczona jako zamknięta. Jest to bardzo ważne pojęcie we wzorcu architektury warstwowej. Warstwa zamknięta oznacza, że gdy żądanie przechodzi z warstwy do warstwy, musi przejść przez warstwę znajdującą się tuż pod nią, aby dostać się do kolejnej warstwy poniżej tej warstwy. Na przykład, żądanie pochodzące z warstwy prezentacji musi najpierw przejść przez warstwę biznesową, a następnie do warstwy trwałości, zanim ostatecznie trafi do warstwy bazy danych.
Rysunek 1-2. Zamknięte warstwy i dostęp do żądania
Dlaczego więc nie pozwolić warstwie prezentacji na bezpośredni dostęp albo do warstwy trwałości, albo do warstwy bazy danych? W końcu bezpośredni dostęp do bazy danych z warstwy prezentacji jest znacznie szybszy niż przechodzenie przez masę niepotrzebnych warstw tylko po to, by pobrać lub zapisać informacje o bazie danych. Odpowiedź na to pytanie leży w kluczowym pojęciu znanym jako warstwy izolacji.
Koncepcja warstw izolacji oznacza, że zmiany dokonane w jednej warstwie architektury na ogół nie wpływają lub wpływają na komponenty w innych warstwach: zmiana jest izolowana do komponentów w obrębie tej warstwy i ewentualnie innej powiązanej warstwy (takiej jak warstwa trwałości zawierająca SQL). Jeśli pozwolisz warstwie prezentacji na bezpośredni dostęp do warstwy trwałości, wtedy zmiany w SQL w warstwie trwałości będą miały wpływ zarówno na warstwę biznesową jak i warstwę prezentacji, tworząc w ten sposób bardzo ściśle powiązaną aplikację z wieloma współzależnościami pomiędzy komponentami. Tego typu architektura staje się wtedy bardzo trudna i kosztowna do zmiany.
Koncepcja warstw izolacji oznacza również, że każda warstwa jest niezależna od innych warstw, przez co posiada niewielką lub żadną wiedzę na temat wewnętrznego działania innych warstw w architekturze. Aby zrozumieć siłę i znaczenie tej koncepcji, rozważmy duży wysiłek refaktoryzacji w celu konwersji szkieletu prezentacji z JSP (Java Server Pages) na JSF (Java Server Faces). Zakładając, że kontrakty (np. model) używane pomiędzy warstwą prezentacji a warstwą biznesową pozostają takie same, warstwa biznesowa nie jest dotknięta refaktoryzacją i pozostaje całkowicie niezależna od typu frameworka interfejsu użytkownika używanego przez warstwę prezentacji.
Pomimo że zamknięte warstwy ułatwiają warstwy izolacji i dlatego pomagają izolować zmiany w architekturze, zdarzają się sytuacje, w których sensowne jest, aby pewne warstwy były otwarte. Na przykład, załóżmy, że chcemy dodać do architektury warstwę usług współdzielonych zawierającą wspólne komponenty usługowe, do których dostęp mają komponenty w warstwie biznesowej (np. klasy narzędziowe danych i ciągów znaków lub klasy audytu i logowania). Utworzenie warstwy usług jest w tym przypadku zazwyczaj dobrym pomysłem, ponieważ architektonicznie ogranicza dostęp do usług współdzielonych do warstwy biznesowej (a nie warstwy prezentacji). Bez oddzielnej warstwy, nie ma nic architektonicznie, co ograniczałoby warstwę prezentacji od dostępu do tych wspólnych usług, co utrudnia zarządzanie tym ograniczeniem dostępu.
W tym przykładzie, nowa warstwa usług prawdopodobnie znajdowałaby się poniżej warstwy biznesowej, aby wskazać, że komponenty w tej warstwie usług nie są dostępne z warstwy prezentacji. Jednakże, to przedstawia problem w tym, że warstwa biznesowa jest teraz wymagana do przejścia przez warstwę usług, aby dostać się do warstwy trwałości, co nie ma żadnego sensu. Jest to odwieczny problem z architekturą warstwową i jest rozwiązywany poprzez tworzenie otwartych warstw w architekturze.
Jak pokazano na rysunku 1-3, warstwa usług w tym przypadku jest oznaczona jako otwarta, co oznacza, że żądania mogą ominąć tę otwartą warstwę i przejść bezpośrednio do warstwy poniżej niej. W poniższym przykładzie, ponieważ warstwa usług jest otwarta, warstwa biznesowa może ją teraz ominąć i przejść bezpośrednio do warstwy trwałości, co ma sens.
Rysunek 1-3. Otwarte warstwy i przepływ żądań
Wykorzystanie koncepcji otwartych i zamkniętych warstw pomaga zdefiniować relacje między warstwami architektury i przepływami żądań, a także dostarcza projektantom i programistom informacji niezbędnych do zrozumienia różnych ograniczeń dostępu do warstw w ramach architektury. Brak udokumentowania lub właściwego przekazania informacji o tym, które warstwy w architekturze są otwarte, a które zamknięte (i dlaczego), zwykle prowadzi do powstania ściśle sprzężonych i kruchych architektur, które są bardzo trudne do przetestowania, utrzymania i wdrożenia.
.