CodeGym /Blog Java /Random-PL /Część 2. Porozmawiajmy trochę o architekturze oprogramowa...
John Squirrels
Poziom 41
San Francisco

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

Opublikowano w grupie Random-PL
Ten materiał jest częścią serii „Wprowadzenie do rozwoju przedsiębiorstwa” . Pierwsza część, dotycząca sieci, znajduje się tutaj . Część 2. Porozmawiajmy trochę o architekturze oprogramowania - 1Architektura oprogramowania odnosi się do struktury utworzonej w aplikacji, tj. modułów i komponentów całego programu oraz ich interakcji. Programiści pracują nad dobrymi architekturami od bardzo dawna, nic więc dziwnego, że słyszeliśmy o wielu wzorcach architektonicznych. Musisz je zrozumieć: podczas pisania aplikacji internetowej bardzo ważne jest, aby wymyślić dobrą architekturę, ponieważ aplikacja internetowa ma więcej komponentów i modułów niż zwykła aplikacja. Wzór architektonicznyto sprytny sposób rozwiązania niektórych problemów związanych z projektowaniem oprogramowania. Prawdopodobnie spotkałeś się z wzorcami projektowymi, takimi jak metoda fabryczna, fabryka abstrakcyjna, konstruktor, prototyp, singleton i być może inne. Używamy ich podczas pisania kodu, tworzenia klas i planowania interakcji między klasami. Wzorce architektoniczne są wykorzystywane na wyższym poziomie abstrakcji, podczas planowania interakcji użytkownika z serwerami, danymi i innymi komponentami. Rzućmy okiem na niektóre wzorce i jak z nich korzystać.

Architektura klient-serwer

Nazwa sprawia wrażenie, że wszystko w tym wzorze jest proste i jasne. Ale wyjaśnijmy sobie kilka kwestii, aby kiedy zaczniesz studiować Spring, zrozumiałeś, o czym mówimy. Załóżmy, że napisałeś aplikację do czatu i zaczynasz jej używać ze znajomym. Możesz zastosować bardzo proste podejście, wysyłając do siebie wiadomości bezpośrednio przez Internet przy użyciu znanych adresów IP: Część 2. Porozmawiajmy trochę o architekturze oprogramowania - 2Na początku wszystko pozornie działa dobrze, dopóki inny znajomy nie poprosi o dołączenie do czatu. Decydując się więc na dodanie wspólnego znajomego do czatu, napotykamy problem architektoniczny: dla każdego uczestnika czatu należy podać aktualne informacje o liczbie użytkowników oraz adresie IP nowych użytkowników. A kiedy wiadomość jest wysyłana, musi zostać dostarczona do wszystkich uczestników. To są najbardziej oczywiste problemy, które się pojawią. Kolejna grupa problemów będzie ukryta w samym kodzie. Aby ich uniknąć, musisz użyć serwera, który będzie przechowywać wszystkie informacje o użytkownikach, w tym ich adresy. Wiadomości muszą być wysyłane tylko na serwer. Ten z kolei wysyła wiadomości do każdego z odbiorców. Decydując się na dodanie części serwerowej do aplikacji czatu, zaczynasz budować architekturę klient-serwer.

Elementy architektury klient-serwer

Zobaczmy, o co w tym wszystkim chodzi. Architektura klient-serwer to wzorzec projektowy używany do tworzenia aplikacji internetowych. Ta architektura składa się z trzech komponentów: Część 2. Porozmawiajmy trochę o architekturze oprogramowania - 3
  1. Klient — na podstawie jego nazwy możemy stwierdzić, że ten komponent korzysta z jakiejś usługi (aplikacji internetowej), kontaktując się z serwerem w celu zażądania pewnych informacji.

  2. Serwer — tutaj znajduje się Twoja aplikacja internetowa lub jej część serwerowa. Przechowuje niezbędne informacje o użytkowniku lub może o nie poprosić. Ponadto, gdy klient wysyła żądanie, to serwer zwraca żądane informacje.

  3. Sieć — Ta część jest prosta. Ułatwia wymianę informacji między klientem a serwerem.

Serwer może obsłużyć ogromną liczbę żądań od różnych użytkowników. Oznacza to, że klientów może być wielu. Jeśli muszą wymieniać między sobą informacje, musi to odbywać się za pośrednictwem serwera. W ten sposób serwer ma inną funkcję: kontrolę ruchu. Jeśli chodzi o nasz program do czatowania dla wielu użytkowników, cała aplikacja będzie składać się z dwóch modułów:
  • moduł klienta — zawiera interfejs graficzny do logowania i wysyłania/odbierania wiadomości

  • moduł 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

Część 2. Porozmawiajmy trochę o architekturze oprogramowania - 4Kiedy chcemy przejrzeć przydatne (lub mało przydatne) informacje w Internecie, otwieramy przeglądarkę, wpisujemy zapytanie w pasku wyszukiwania iw odpowiedzi uzyskujemy informacje z wyszukiwarki. W tym łańcuchu przeglądarka jest klientem. Wysyła do serwera zapytanie z informacją o tym, czego szukamy. Serwer przetwarza żądanie, znajduje najbardziej odpowiednie wyniki, pakuje je w formacie zrozumiałym dla przeglądarki (klienta) i odsyła je z powrotem. Złożone usługi, takie jak wyszukiwarki, mogą mieć wiele serwerów. Na przykład serwer autoryzacji, serwer do wyszukiwania informacji, serwer do generowania odpowiedzi itp. Ale klient nie jest tego świadomy i nie przejmuje się tym: dla klienta serwer jest jednolitą jednostką. Klient wie tylko o punkcie wejścia, czyli adres serwera, na który mają być kierowane żądania. Przypomnij sobie aplikację, w której sprawdzaliśmypoprzednia część tej serii . Służył do monitorowania średniej temperatury powietrza we wszystkich krajach w czasie rzeczywistym. Jego architektura wygląda mniej więcej tak: Część 2. Porozmawiajmy trochę o architekturze oprogramowania - 5Nasza aplikacja znajduje się na serwerze. Powiedzmy, że co pięć sekund wysyła żądania do serwerów obsługiwanych przez lokalne stacje meteorologiczne, odbiera z serwerów informacje o temperaturze dla danego kraju i przechowuje te informacje. Kiedy klient prosi nas o „zobaczenie aktualnej temperatury powietrza na świecie”, zwracamy ostatnio zapisane informacje, posortowane według kraju. Dzięki temu nasza aplikacja działa zarówno jako serwer (gdy przetwarza zapytania użytkowników), jak i klient (gdy otrzymuje informacje z innych serwerów).
Oto ważna kwestia: koncepcja serwera nie dotyczy konkretnego komputera, ale raczej relacji między jednostkami sieciowymi .
Prosta architektura klient-serwer jest używana bardzo rzadko i tylko dla bardzo prostych aplikacji. Przy naprawdę dużych i skomplikowanych projektach stosujemy różne architektury, z którymi spotkasz się w przyszłości. Przyjrzyjmy się teraz modelowi, który jest bardzo podobny do architektury klient-serwer.

Architektura trójwarstwowa

Jest to wzorzec architektoniczny, który wprowadza trzeci moduł — przechowywanie danych . W tym wzorze trzy poziomy są zwykle nazywane warstwami lub poziomami: Część 2. Porozmawiajmy trochę o architekturze oprogramowania - 6
  1. Warstwa klienta to interfejs użytkownika, zwany także warstwą prezentacji. Może to być przeglądarka internetowa odbierająca strony HTML lub graficzny interfejs użytkownika napisany przy użyciu JavaFX. Najważniejsze jest to, że ta warstwa pozwala użytkownikowi wysyłać żądania do serwera i przetwarzać jego odpowiedzi.

  2. Warstwa logiczna to serwer przetwarzający żądania/odpowiedzi. Często nazywana jest również warstwą serwerową. Tutaj również odbywają się wszystkie operacje logiczne: obliczenia matematyczne, operacje na danych, połączenia z innymi usługami lub magazynami danych itp.

  3. Warstwa danych to serwer bazy danych: nasz serwer z nim współdziała. W tej warstwie przechowywane są wszystkie informacje niezbędne do działania aplikacji.

W związku z tym nasz serwer przejmuje pełną odpowiedzialność za dostęp do danych i nie umożliwia użytkownikowi bezpośredniego dostępu do nich.

Zalety architektury trójwarstwowej

Taka architektura daje nam wiele korzyści, m.in.:
  1. Możliwość ochrony przed SQL injection (jest to atak na serwer; polega na wysłaniu kodu SQL, który po wykonaniu umożliwia atakującemu wpływ na naszą bazę danych).

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

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

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

  5. Mniej rygorystyczne wymagania dotyczące jakości połączeń użytkowników. Generując odpowiedź na serwerze, często pobieramy z bazy danych wiele różnych informacji i formatujemy ją, pozostawiając tylko to, czego potrzebuje użytkownik. W ten sposób zmniejsza się ilość informacji, które wysyłamy w naszej odpowiedzi do klienta.

Jak często należy stosować wzorce architektoniczne?

Jeśli znasz, powiedzmy, wzorzec projektowy metody fabrycznej , prawdopodobnie zastanawiałeś się, kiedy go używać. Czasami trudno zdecydować, co zrobić: utworzyć obiekt przy użyciu operatora new lub metody fabrycznej. Ale z czasem przychodzi zrozumienie. Nieco inaczej sprawa wygląda, jeśli chodzi o wzorce architektoniczne. Frameworki korporacyjne mają na celu umożliwienie programiście stworzenia projektu w oparciu o jakiś ogólnie przyjęty wzorzec. W związku z tym, zanim nauczysz się Spring Framework, zdecydowanie powinieneś zrozumieć architekturę klient-serwer, architekturę trójwarstwową i architekturę MVC. Nie martw się: jeszcze porozmawiamy o architekturze MVC. Część 3. HTTP/HTTPS Część 4. Podstawy Mavena Część 5. Serwlety i Java Servlet API. Pisanie prostej aplikacji webowej Część 6. Kontenery serwletów Część 7. Wprowadzenie do wzorca MVC (Model-View-Controller)
Komentarze
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION