Część 2. Porozmawiajmy trochę o architekturze oprogramowania

Materiał ten stanowi część serii „ Wprowadzenie do rozwoju przedsiębiorstwa ”. Pierwsza część o sieci jest tutaj . Architektura oprogramowania to struktura, w oparciu o którą tworzona jest aplikacja, a moduły i komponenty całego programu współdziałają ze sobą. Programiści od bardzo dawna starają się stworzyć dobrą architekturę, nic więc dziwnego, że znamy obecnie wiele wzorców architektonicznych. Trzeba je zrozumieć: kiedy piszesz aplikację internetową, problem architektury staje się dotkliwy, ponieważ jest w niej więcej komponentów i modułów niż w zwykłej aplikacji. Wzorzec architektoniczny to już przemyślany sposób rozwiązania jakiegoś problemu związanego z projektowaniem oprogramowania. Prawdopodobnie spotkałeś się już z wzorcami projektowymi, takimi jak Factory Method, Abstract Factory, Builder, Prototype, Singleton i być może inne. Służą do prostego pisania kodu, tworzenia klas i planowania interakcji. Wzorce architektoniczne wykorzystywane są na wyższym poziomie abstrakcji – przy planowaniu interakcji użytkownika aplikacji z serwerem, danymi i innymi elementami projektu. Przyjrzyjmy się pokrótce niektórym szablonom i sposobom ich użycia.

Architektura klient-serwer

Z nazwy można odnieść wrażenie, że wszystko w tym temacie jest proste i przejrzyste. Ale wyjaśnijmy kilka punktów, abyś kiedy zaczniesz studiować warunkową wiosnę, dokładnie zrozumiał, o czym mówimy. Załóżmy, że napisałeś czat i ty i twój znajomy zaczynacie z niego korzystać. Możliwa jest tutaj prosta opcja - wysyłacie do siebie wiadomość bezpośrednio przez Internet, korzystając ze znanych Wam adresów IP: Na początku może się wydawać, że wszystko działa dobrze, dopóki nie pojawi się inny Wasz znajomy z pytaniem: „Dlaczego nie nie dodałeś mnie do swojego czatu?” A kiedy zdecydujesz się dodać wspólnego znajomego do czatu, stajesz przed problemem architektonicznym: każdy użytkownik czatu musi zaktualizować informacje o liczbie użytkowników, dodać adres IP nowego użytkownika. A wysyłając wiadomość, należy ją dostarczyć wszystkim uczestnikom. To są najbardziej oczywiste problemy, jakie się pojawią. O wiele więcej problemów będzie ukrytych w samym kodzie. Aby ich uniknąć, trzeba skorzystać z serwera , który będzie przechowywać wszystkie informacje o użytkownikach i zna ich adresy. Wiadomość będzie musiała zostać jedynie wysłana na serwer. A on z kolei wyśle ​​wiadomość do wszystkich odbiorców. Kiedy zdecydujesz się dodać stronę serwera do swojego czatu, zaczniesz budować architekturę klient-serwer.

Elementy architektury klient-serwer

Dowiedzmy się, czym ona jest. Architektura klient-serwer jest wzorcem projektowym, podstawą tworzenia aplikacji internetowych. Architektura ta składa się z trzech komponentów:

1. Klient - z nazwy jasno wynika, że ​​jest to użytkownik usługi (aplikacji internetowej), który kontaktuje się z serwerem w celu uzyskania pewnych informacji.

2. Serwer to miejsce, w którym znajduje się Twoja aplikacja internetowa lub jej część serwerowa. Jest właścicielem niezbędnych informacji o użytkownikach lub może o nie poprosić. Ponadto, gdy klient się kontaktuje, serwer zwraca żądane informacje.

3. Sieć jest prosta: zapewnia wymianę informacji pomiędzy klientem a serwerem.

Serwer może przetwarzać ogromną liczbę żądań od różnych użytkowników. Oznacza to, że klientów może być wielu i jeśli będą musieli wymieniać między sobą informacje, będzie to musiało odbywać się za pośrednictwem serwera. Tym samym serwer otrzymuje jeszcze jedną dodatkową funkcję – kontrolę ruchu. Jeśli mówimy o stworzonym przez nas czacie dla wielu użytkowników, cały kod programu będzie składał się z dwóch modułów:

• klient - zawiera graficzny interfejs do autoryzacji, wysyłania/odbierania wiadomości;

• po stronie serwera - aplikacja internetowa, która jest hostowana na serwerze i odbiera wiadomości od użytkowników, przetwarza je, a następnie wysyła do odbiorców.

Kiedy chcemy zajrzeć do przydatnych (lub mniej przydatnych) informacji w Internecie, otwieramy przeglądarkę, w pasku wyszukiwania wpisujemy zapytanie, a w odpowiedzi otrzymujemy informację z wyszukiwarki. W tym łańcuchu naszym klientem jest przeglądarka. Wysyła do serwera żądanie z informacją o tym, czego szukamy. Serwer przetwarza żądanie, znajduje najbardziej odpowiednie wyniki, pakuje je do formatu zrozumiałego dla przeglądarki (klienta) i odsyła. W tak skomplikowanych usługach, jak wyszukiwarki, serwerów może być wiele. Np. serwer autoryzacyjny, serwer wyszukiwania informacji, serwer generowania odpowiedzi. Ale klient nic o tym nie wie: dla niego serwer jest czymś jednolitym. Klient zna jedynie punkt wejścia, czyli adres serwera, do którego ma wysłać żądanie. Przypomnijmy sobie aplikację, o której wspominaliśmy w poprzedniej części - służącą do monitorowania w czasie rzeczywistym średniej temperatury powietrza we wszystkich krajach. Jej architektura będzie wyglądać mniej więcej tak: Nasza aplikacja znajduje się na serwerze. Załóżmy, że co pięć sekund wysyła żądania do serwerów lokalnych ośrodków hydrometeorologicznych, odbiera od nich informacje o temperaturze w danym kraju i przechowuje te informacje. Gdy klient kontaktuje się z nami z prośbą o „zobaczenie aktualnej temperatury powietrza na świecie”, zwracamy najnowsze zapisane informacje, posortowane według krajów. Tym samym nasza aplikacja jest zarówno serwerem (gdy przetwarza żądania użytkowników), jak i klientem (gdy otrzymuje informacje z innych serwerów). Prosta architektura klient-serwer jest stosowana bardzo rzadko i tylko w przypadku bardzo prostych aplikacji. W przypadku naprawdę dużych i skomplikowanych projektów stosuje się różne typy architektur, z którymi zapoznasz się bliżej w przyszłości. Przyjrzyjmy się teraz modelowi bardzo podobnemu do modelu klient-serwer.

Architektura trójpoziomowa

Jest to wzorzec architektoniczny, który wprowadza trzeciego gracza: hurtownię danych . Podczas korzystania z tego wzorca trzy poziomy są zwykle nazywane warstwami:

1. Warstwa klienta to interfejs użytkownika. Może to być przeglądarka internetowa, do której wysyłane są strony HTML, lub aplikacja GUI napisana przy użyciu języka JavaFX. Najważniejsze jest to, że za jego pomocą użytkownik może wysyłać żądania do serwera i przetwarzać jego odpowiedzi.

2. Warstwa logiczna to serwer, na którym przetwarzane są żądania/odpowiedzi. Często nazywana jest także warstwą serwerową. Odbywają się tu także wszelkie operacje logiczne: obliczenia matematyczne, operacje na danych, wywołania innych usług czy przechowywanie danych.

3. Warstwa danych to serwer bazy danych: nasz serwer uzyskuje do niej dostęp. Warstwa ta przechowuje wszystkie niezbędne informacje, z których aplikacja korzysta podczas działania.

W ten sposób nasz serwer przejmuje wszelkie obowiązki związane z dostępem do danych, nie pozwalając użytkownikowi na bezpośredni dostęp do nich.

Korzyści z architektury trójwarstwowej

Stosując taką architekturę uzyskujemy wiele korzyści, m.in.:

1. Możliwość zbudowania ochrony przed iniekcjami SQL to atak na serwer, na którym przesyłany jest kod SQL, a po wykonaniu tego kodu atakujący może wpłynąć na naszą bazę danych.

2. Wyznaczenie danych, do których chcemy regulować dostęp użytkowników.

3. Możliwość modyfikacji danych przed wysłaniem ich do klienta.

4. Skalowalność - możliwość rozbudowy naszej aplikacji na kilka serwerów, które będą korzystały z tej samej bazy danych.

5. Mniejsze wymagania dotyczące jakości połączenia użytkownika. Generując odpowiedź na serwerze często pobieramy z bazy danych wiele różnych informacji, formatujemy ją, zostawiając tylko to, czego potrzebuje użytkownik. W ten sposób ograniczamy ilość informacji, które wysyłamy w odpowiedzi do klienta.

Jak często warto wykorzystywać wzorce architektoniczne?

Jeśli znasz, powiedzmy, wzorzec projektowy Metody Fabrycznej , prawdopodobnie zastanawiałeś się, kiedy go użyć. Czasami trudno się zdecydować, co zrobić: utworzyć obiekt za pomocą operatora new, czy użyć metody fabrycznej. Ale z czasem przychodzi zrozumienie. W przypadku wzorców architektonicznych sprawa wygląda nieco inaczej. Frameworki korporacyjne są zaprojektowane tak, aby programista mógł za ich pomocą stworzyć projekt oparty na jakimś ogólnie przyjętym wzorcu. Dlatego przed nauczeniem się Spring Framework zdecydowanie musisz zrozumieć, czym jest architektura klient-serwer, architektura trójwarstwowa i architektura MVC. Nie martw się: o architekturze MVC porozmawiamy później. Część 1. Co musisz wiedzieć przed nauczeniem się Springa i JavaEE Część 3. Protokoły HTTP/HTTPS Część 4. Podstawy Mavena Część 5. Serwlety. Pisanie prostej aplikacji internetowej Część 6. Kontenery serwletów Część 7. Wprowadzenie do wzorca MVC (Model-View-Controller) Część 8. Pisanie małej aplikacji uruchamianej w trybie spring-boot