Część 7. Wprowadzenie do wzorca MVC (Model-View-Controller).

Materiał ten stanowi część serii „Wprowadzenie do rozwoju przedsiębiorstwa”. Poprzednie artykuły:

• o sieci ;
• o architekturze oprogramowania ;
• o protokołach HTTP/HTTPS ;
• o podstawach Mavena ;
• o serwletach (piszemy prostą aplikację internetową) ;
• o kontenerach serwletów .

W tym materiale przybliżymy Ci coś takiego jak MVC. Porozmawiajmy o tym czym jest MVC, dotknijmy historii jego powstania, poznajmy główne idee i koncepcje tkwiące w MVC, rozważmy krok po kroku jak rozbić aplikację na moduły Modelu, Widoku, Kontrolera, a także napiszmy małą aplikację internetową w języku Spring-Boot i używając Spring-MVC jako przykładu, zobaczmy, jak dane są przesyłane z kodu Java do stron HTML. Aby zrozumieć ten materiał, trzeba znać wzorce projektowe, zwłaszcza Observer i Facade. Zapoznaj się z żądaniami i odpowiedziami HTTP, zrozum podstawy HTML, dowiedz się, czym są adnotacje w Javie. Usiądź wygodnie, zaparz herbatę, przygotuj deser, sałatkę, danie główne i pierwsze danie. Zaczynamy.

Historia MVC

Pomysły na MVC zostały sformułowane przez Trygve Reenskauga podczas pracy w Xerox PARC pod koniec lat 70-tych. W tamtych czasach praca z komputerem nie mogła obejść się bez stopnia naukowego i ciągłego studiowania obszernej dokumentacji. Problemem, który Reenskaug rozwiązał wraz z grupą bardzo silnych programistów, było uproszczenie interakcji przeciętnego użytkownika z komputerem. Należało stworzyć narzędzia, które z jednej strony byłyby niezwykle proste i zrozumiałe, a z drugiej umożliwiłyby zarządzanie komputerem i złożonymi aplikacjami. Reenskaug pracował w zespole, który pod przewodnictwem Alana Kaya opracował przenośny komputer „dla dzieci w każdym wieku” – Dynabook, a także język SmallTalk. To właśnie wtedy narodziły się koncepcje przyjaznego interfejsu. Praca Reenskauga ze swoim zespołem znacząco wpłynęła na rozwój branży IT. Przedstawmy ciekawostkę, która nie dotyczy bezpośrednio MVC, ale ilustruje wagę tych zmian. W 2007 roku, po prezentacji Apple iPhone, Alan Kay powiedział: „Kiedy pojawił się komputer Macintosh, Newsweek zapytał, co o nim myślę. Powiedziałem: to pierwszy komputer osobisty godny krytyki. Po prezentacji podszedł Steve Jobs i zapytał: czy iPhone zasługuje na krytykę? Powiedziałem: zrób pięć na osiem cali, a podbijesz świat. Trzy lata później, 27 stycznia 2010 roku, firma Apple wprowadziła na rynek iPada o przekątnej 9,7 cala. Oznacza to, że Steve Jobs niemal dosłownie zastosował się do rad Alana Kaya. Projekt, nad którym pracował Rennskaug, trwał 10 lat. A pierwsza publikacja o MVC od jego twórców ukazała się kolejne 10 lat później. Martin Fowler, autor wielu książek i artykułów na temat architektury oprogramowania, wspomina, że ​​MVC nauczył się z działającej wersji SmallTalk. Ponieważ przez długi czas w pierwotnym źródle nie było informacji o MVC, a także z szeregu innych powodów, pojawiło się wiele różnych interpretacji tego pojęcia. W rezultacie wiele osób uważa MVC za schemat lub wzorzec projektowy. Rzadziej MVC nazywany jest wzorcem złożonym lub kombinacją kilku wzorców, które współpracują w celu implementacji złożonych aplikacji. Ale tak naprawdę, jak powiedziano wcześniej, MVC to przede wszystkim zbiór pomysłów/zasad/podejść architektonicznych, które można wdrożyć na różne sposoby, korzystając z różnych wzorców... Następnie spróbujemy przyjrzeć się głównym ideom zawartym w koncepcji MVC.

Co to jest MVC: podstawowe idee i zasady

• VC to zbiór pomysłów i zasad architektonicznych służących do budowania złożonych systemów informatycznych z interfejsem użytkownika;
• MVC to akronim oznaczający kontroler widoku modelu.

Zastrzeżenie: MVC nie jest wzorcem projektowym. MVC to właśnie zbiór pomysłów architektonicznych i zasad budowania złożonych systemów z interfejsem użytkownika. Ale dla wygody, żeby nie powtarzać za każdym razem: „Zestaw pomysłów architektonicznych…”, MVC nazwiemy wzorcem. Zacznijmy od czegoś prostego. Co kryje się za słowami Model-View-Controller? Tworząc systemy z interfejsem użytkownika, zgodnie ze wzorcem MVC, należy podzielić system na trzy komponenty. Te z kolei można nazwać modułami lub komponentami. Mów, co chcesz, ale podziel przez trzy. Każdy komponent będzie miał swój własny cel. Model. Pierwszy komponent/moduł to tzw. model. Zawiera całą logikę biznesową aplikacji. Pogląd. Drugą częścią systemu jest widok. Moduł ten odpowiada za wyświetlanie danych użytkownikowi. Wszystko, co widzi użytkownik, jest generowane przez widok. Kontroler. Trzecim ogniwem tego łańcucha jest kontroler. Przechowuje kod odpowiedzialny za przetwarzanie działań użytkownika (każda akcja użytkownika w systemie jest przetwarzana w kontrolerze). Model jest najbardziej niezależną częścią systemu. Tak niezależny, że nie powinien nic wiedzieć o modułach View i Controller. Model jest na tyle niezależny, że jego twórcy mogą nie wiedzieć praktycznie nic o widoku i kontrolerze. Głównym celem widoku jest dostarczenie informacji z modelu w formacie przyjaznym dla użytkownika. Głównym ograniczeniem widoku jest to, że nie powinien on w żaden sposób zmieniać modelu. Głównym celem Administratora jest przetwarzanie działań użytkowników. To za pośrednictwem Kontrolera użytkownik dokonuje zmian w modelu. Dokładniej, do danych przechowywanych w modelu. Przytoczmy jeszcze raz schemat, który został już Państwu pokazany na wykładzie: Z tego wszystkiego możemy wyciągnąć całkowicie logiczny wniosek. Złożony system należy podzielić na moduły. Opiszmy pokrótce kroki prowadzące do osiągnięcia takiego rozdzielenia.

Krok 1: Oddziel logikę biznesową aplikacji od interfejsu użytkownika

Kluczową ideą MVC jest to, że dowolną aplikację posiadającą interfejs użytkownika można w pierwszym przybliżeniu podzielić na 2 moduły: moduł odpowiedzialny za realizację logiki biznesowej aplikacji oraz interfejs użytkownika. Pierwszy moduł będzie implementował główną funkcjonalność aplikacji. Moduł ten będzie rdzeniem systemu, w którym zaimplementowany jest model domeny aplikacji. W koncepcji MVC modułem tym będzie nasza litera M, czyli. Model. Drugi moduł zaimplementuje cały interfejs użytkownika, łącznie z wyświetlaniem danych użytkownikowi i logiką interakcji użytkownika z aplikacją. Głównym celem tej separacji jest zapewnienie, że rdzeń systemu (Model w terminologii MVC) może być niezależnie rozwijany i testowany. Architektura aplikacji po takim podziale będzie wyglądać następująco:

Krok 2. Korzystając ze wzorca Observer, osiągnij jeszcze większą niezależność modelu, a także synchronizację interfejsów użytkownika

Tutaj realizujemy 2 cele:

1. Osiągnij jeszcze większą niezależność modelu.
2. Synchronizuj interfejsy użytkownika.

Poniższy przykład pomoże Ci zrozumieć, co oznacza synchronizacja interfejsów użytkownika. Załóżmy, że kupujemy bilet do kina przez internet i sprawdzamy, ile jest wolnych miejsc w kinie. Ktoś inny może kupić bilet do kina w tym samym czasie co my. Jeśli ten ktoś kupi bilet przed nami, chcielibyśmy, aby liczba dostępnych miejsc na naszą sesję spadła. Zastanówmy się teraz, jak można to zaimplementować w programie. Załóżmy, że mamy rdzeń systemu (nasz model) i interfejs (stronę internetową, na której dokonujemy zakupu). Na stronie 2 użytkowników jednocześnie wybiera miejsce. Pierwszy użytkownik kupił bilet. Drugi użytkownik musi wyświetlić tę informację na stronie. Jak powinno się to zdarzyć? Jeśli zaktualizujemy interfejs z jądra systemu, nasze jądro, nasz model, będzie zależny od interfejsu. Podczas opracowywania i testowania modelu trzeba będzie mieć na uwadze różne sposoby aktualizacji interfejsu. Aby to osiągnąć, musisz zaimplementować wzorzec Observer. Za jego pomocą model wysyła powiadomienia o zmianach do wszystkich abonentów. Interfejs będąc takim abonentem otrzyma powiadomienie i aktualizację. Wzorzec Observer pozwala modelowi z jednej strony poinformować interfejs (widok i kontroler), że zaszły w nim zmiany, a z drugiej strony tak naprawdę nic o nich „nie wiedzieć” i tym samym zachować niezależność. Z drugiej strony umożliwi to synchronizację interfejsów użytkownika.

Krok 3. Podział interfejsu na Widok i Kontroler

Nadal dzielimy aplikację na moduły, ale na niższym poziomie hierarchii. W tym kroku interfejs użytkownika (który w kroku 1 został wydzielony na osobny moduł) dzieli się na widok i kontroler. Trudno jest narysować ścisłą granicę między widokiem a kontrolerem. Jeśli powiemy, że widok jest tym, co widzi użytkownik, a kontroler to mechanizm, za pomocą którego użytkownik może wchodzić w interakcję z systemem, to pojawia się pewna sprzeczność. Elementy sterujące, takie jak przyciski na stronie internetowej lub wirtualna klawiatura na ekranie telefonu, są zasadniczo częścią kontrolera. Ale są one tak samo widoczne dla użytkownika, jak każda część widoku. Tutaj mówimy bardziej o podziale funkcjonalnym. Głównym zadaniem interfejsu użytkownika jest zapewnienie interakcji użytkownika z systemem. Oznacza to, że interfejs posiada tylko 2 funkcje:

• wyświetlać i wygodnie wyświetlać użytkownikowi informacje o systemie;
• wprowadzać do systemu dane użytkownika i polecenia (przesyłać je do systemu);

Funkcje te określają sposób podziału interfejsu na moduły. W rezultacie architektura systemu wygląda następująco: Mamy więc aplikację składającą się z trzech modułów o nazwie Model, Widok i Kontroler. Podsumowując:

1. Zgodnie z zasadami MVC system należy podzielić na moduły.
2. Najważniejszym i niezależnym modułem powinien być model.
3. Model jest rdzeniem systemu. Potrzebujesz umiejętności jego rozwijania i testowania niezależnie od interfejsu.
4. Aby to zrobić, na pierwszym etapie segregacji systemu należy podzielić go na model i interfejs.
5. Następnie wykorzystując wzorzec Observer wzmacniamy niezależność modelu i uzyskujemy synchronizację interfejsów użytkownika.
6. Trzecim krokiem jest podzielenie interfejsu na kontroler i widok.
7. Wszystko, co jest potrzebne do wprowadzenia informacji od użytkownika do systemu, znajduje się w kontrolerze.
8. Wszystko, co wysyła informacje z systemu do użytkownika, jest widoczne.

Została jeszcze jedna ważna sprawa do omówienia i można pić kakao.

Trochę o relacji pomiędzy Widokiem, Kontrolerem i Modelem

Kiedy użytkownik wprowadza informacje za pośrednictwem kontrolera, wprowadza w ten sposób zmiany w modelu. Przynajmniej użytkownik wprowadza zmiany w danych modelu. Kiedy użytkownik otrzymuje informacje poprzez elementy interfejsu (poprzez Widok), otrzymuje informację o danych modelu. Jak to się stało? W jaki sposób widok i kontroler współdziałają z modelem? Przecież nie może być tak, że klasy View bezpośrednio korzystają z metod klas Model do odczytu/zapisu danych, w przeciwnym razie nie może być mowy o jakiejkolwiek niezależności Modelu. Model reprezentuje ściśle połączony zestaw klas, do których, w dobrym tego słowa znaczeniu, ani Widok, ani Kontroler nie powinny mieć dostępu. Aby połączyć Model z Widokiem i Kontrolerem konieczne jest wdrożenie wzorca projektowego Fasada. Fasada modelu będzie warstwą pomiędzy Modelem a interfejsem, poprzez którą Widok otrzyma dane w dogodnym formacie, a Kontroler dokona zmiany danych wywołując niezbędne metody fasady. Schematycznie ostatecznie wszystko będzie wyglądać tak:

MVC: jaka jest korzyść?

Głównym celem stosowania zasad MVC jest oddzielenie implementacji logiki biznesowej aplikacji (modelu) od jej wizualizacji (widoku). To oddzielenie zwiększy ponowne wykorzystanie kodu. Korzyści ze stosowania MVC są najbardziej oczywiste w przypadkach, gdy użytkownik musi podać te same dane w różnych formach. Na przykład w formie tabeli, wykresu lub wykresu (przy użyciu różnych typów). Jednocześnie, bez wpływu na realizację widoków, możesz zmieniać reakcje na działania użytkownika (kliknięcie przycisku, wprowadzenie danych). Kierując się zasadami MVC, można uprościć pisanie programów, zwiększyć czytelność kodu oraz ułatwić rozbudowę i utrzymanie systemu w przyszłości. W końcowym materiale z serii „Wprowadzenie do rozwoju przedsiębiorstw” przyjrzymy się implementacji MVC na przykładzie Spring-MVC. Część 8. Pisanie małej aplikacji w spring-boocie