W tym artykule poznamy coś, co nazywa się MVC. Porozmawiamy o tym, czym jest MVC, dotkniemy jego historii, zbadamy podstawowe idee i koncepcje zawarte w MVC, przyjrzymy się krok po kroku, jak podzielić aplikację na moduły Model, View i Controller, napiszemy małej aplikacji internetowej korzystającej z Spring Boot i na przykładzie Spring MVC zobaczyć, jak dane są przesyłane z kodu Java do stron HTML. Aby zrozumieć ten materiał, musisz znać wzorce projektowe, zwłaszcza obserwatora i elewacji. Zapoznaj się z żądaniami i odpowiedziami HTTP, zrozum podstawy języka HTML i dowiedz się, czym są adnotacje Java. Weź filiżankę kawy i przekąskę i usiądź wygodnie. Zaczynajmy.
Historia MVC
Idee stojące za MVC zostały sformułowane przez Trygve'a Reenskauga podczas pracy w Xerox PARC pod koniec lat 70. W tamtych czasach praca z komputerem wymagała pewnego stopnia i ciągłego studiowania obszernej dokumentacji. Zadaniem, które Reenskaug rozwiązał wraz z grupą bardzo silnych programistów, było uproszczenie interakcji zwykłego użytkownika z komputerem. Konieczne było stworzenie narzędzi, które z jednej strony byłyby niezwykle proste i zrozumiałe, az drugiej umożliwiałyby sterowanie komputerami i złożonymi aplikacjami. Reenskaug pracował w zespole, który opracował laptop „dla dzieci w każdym wieku” — Dynabook, a także język SmallTalk pod kierownictwem Alana Kaya. Wtedy powstały koncepcje przyjaznego interfejsu. pod wieloma względami praca wykonana przez Reenskauga i jego zespół wpłynęła na ewolucję sfery IT. Oto interesujący fakt, który nie odnosi się bezpośrednio do MVC, ale ilustruje znaczenie tych zmian. Alana Kay'apowiedział, „Kiedy po raz pierwszy spotkałem się z Apple, czyli w 1984 roku, komputer Mac był już dostępny, a Newsweek skontaktował się ze mną i zapytał, co myślę o Macu. Odpowiedziałem: „Cóż, Mac to pierwszy komputer osobisty na tyle dobry, by być krytykowanym. Tak więc, po ogłoszeniu iPhone'a w 2007 roku, przyniósł mi go i wręczył. Powiedział: „Alan, czy to jest wystarczająco dobre, by być krytykowanym?” I powiedziałem: „Steve, spraw, aby był tak duży jak tablet, a będziesz rządził światem”. Po 3 latach, 27 stycznia 2010 r., Apple wprowadziło iPada o przekątnej 9,7 cala. Innymi słowy, Steve Jobs prawie dokładnie zastosował się do rady Alana Kaya. Projekt Reenskauga trwał 10 lat. Ale pierwsza publikacja o MVC wyszła na jaw po kolejnych 10 latach. Martin Fowler, autor kilku książek i artykułów na temat architektury oprogramowania, wspomina, że studiował MVC przy użyciu działającej wersji Smalltalk. Ponieważ przez długi czas nie było informacji o MVC z pierwotnego źródła, a także z kilku innych powodów, pojawiła się duża liczba różnych interpretacji tego pojęcia. W rezultacie wielu uważa MVC za wzorzec projektowy. Rzadziej MVC jest nazywany złożonym wzorcem lub kombinacją kilku wzorców, które współpracują ze sobą, tworząc złożone aplikacje. Ale, jak wspomniano wcześniej, MVC jest w rzeczywistości przede wszystkim zbiorem pomysłów/zasad/podejść architektonicznych, które można zaimplementować na różne sposoby przy użyciu różnych wzorców... Następnie rozważymy główne idee osadzone w koncepcji MVC. iz kilku innych powodów pojawiła się duża liczba różnych interpretacji tego pojęcia. W rezultacie wielu uważa MVC za wzorzec projektowy. Rzadziej MVC jest nazywany złożonym wzorcem lub kombinacją kilku wzorców, które współpracują ze sobą, tworząc złożone aplikacje. Ale, jak wspomniano wcześniej, MVC jest w rzeczywistości przede wszystkim zbiorem pomysłów/zasad/podejść architektonicznych, które można zaimplementować na różne sposoby przy użyciu różnych wzorców... Następnie rozważymy główne idee osadzone w koncepcji MVC. iz kilku innych powodów pojawiła się duża liczba różnych interpretacji tego pojęcia. W rezultacie wielu uważa MVC za wzorzec projektowy. Rzadziej MVC jest nazywany złożonym wzorcem lub kombinacją kilku wzorców, które współpracują ze sobą, tworząc złożone aplikacje. Ale, jak wspomniano wcześniej, MVC jest w rzeczywistości przede wszystkim zbiorem pomysłów/zasad/podejść architektonicznych, które można zaimplementować na różne sposoby przy użyciu różnych wzorców... Następnie rozważymy główne idee osadzone w koncepcji MVC.
MVC: Podstawowe idee i zasady
VC to zbiór pomysłów architektonicznych i zasad budowania złożonych systemów informatycznych z interfejsem użytkownika
MVC to skrót oznaczający: Model-View-Controller
Zastrzeżenie: MVC nie jest wzorcem projektowym. MVC to zbiór pomysłów architektonicznych i zasad budowania złożonych systemów z interfejsem użytkownika. Ale dla wygody, aby nie powtarzać w kółko „zbiór pomysłów architektonicznych…”, odniesiemy się do wzorca MVC. Zacznijmy od prostego. Co kryje się za słowami Model-View-Controller? Używając wzorca MVC do tworzenia systemów z interfejsem użytkownika, należy podzielić system na trzy komponenty. Można je również nazwać modułami lub komponentami. Nazywaj je jak chcesz, ale podziel system na trzy komponenty. Każdy składnik ma swój własny cel. Model. Pierwszy komponent/moduł nazywany jest modelem. Zawiera całą logikę biznesową aplikacji. Pogląd.Drugim elementem systemu jest widok. Moduł ten odpowiada za wyświetlanie danych użytkownikowi. Wszystko, co widzi użytkownik, jest generowane przez widok. Kontroler.Trzecim ogniwem w tym łańcuchu jest kontroler. Zawiera kod odpowiedzialny za obsługę akcji użytkownika (wszystkie akcje użytkownika są obsługiwane w kontrolerze). Model jest najbardziej niezależną częścią systemu. Tak niezależny, że nie może nic wiedzieć o modułach widoku i kontrolera. Model jest tak 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, który może wykorzystać użytkownik. Głównym ograniczeniem widoku jest to, że nie może on w żaden sposób zmieniać modelu. Głównym celem kontrolera jest obsługa działań użytkownika. To za pośrednictwem kontrolera użytkownik dokonuje zmian w modelu. A dokładniej do danych, które są przechowywane w modelu. Oto diagram, który widziałeś wcześniej na lekcji: Z tego wszystkiego możemy wyciągnąć logiczny wniosek. Złożony system należy podzielić na moduły. Opiszmy pokrótce kroki prowadzące do osiągnięcia tego rozdzielenia.
Krok 1. Oddziel logikę biznesową aplikacji od interfejsu użytkownika
Główną ideą MVC jest to, że każdą aplikację z interfejsem użytkownika można podzielić na 2 moduły: moduł odpowiedzialny za implementację logiki biznesowej oraz interfejs użytkownika. Pierwszy moduł zaimplementuje główną funkcjonalność aplikacji. Moduł ten jest rdzeniem systemu, w którym realizowany jest model domenowy aplikacji. W paradygmacie MVC tym modułem jest litera M, czyli model. Drugi moduł implementuje cały interfejs użytkownika, w tym logikę do wyświetlania danych użytkownikowi i obsługi 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. Po wykonaniu tej separacji architektura aplikacji wygląda następująco:
Krok 2 Użyj wzorca obserwatora, aby uczynić model jeszcze bardziej niezależnym i zsynchronizować interfejsy użytkownika
Tutaj mamy 2 cele:
Osiągnij jeszcze większą niezależność modelu
Synchronizuj interfejsy użytkownika
Poniższy przykład pomoże Ci zrozumieć, co rozumiemy przez synchronizację interfejsów użytkownika. Załóżmy, że kupujemy bilet do kina online i sprawdzamy liczbę dostępnych miejsc w kinie. W tym samym czasie ktoś inny może kupować bilet do kina. Jeśli ta druga osoba kupi bilet przed nami, chcielibyśmy zobaczyć spadek liczby dostępnych miejsc na seans, który rozważamy. Pomyślmy teraz, jak można to zaimplementować w programie. Załóżmy, że mamy rdzeń naszego systemu (nasz model) i interfejs (stronę internetową do kupowania biletów). Dwóch użytkowników próbuje jednocześnie wybrać miejsce w teatrze. Pierwszy użytkownik kupuje bilet. Strona internetowa musi pokazać drugiemu użytkownikowi, że tak się stało. Jak to ma się stać? Jeśli zaktualizujemy interfejs z rdzenia, wtedy rdzeń (nasz model) będzie zależny od interfejsu. Podczas opracowywania i testowania modelu będziemy musieli pamiętać o różnych sposobach aktualizacji interfejsu. Aby to osiągnąć, musimy zaimplementować wzorzec obserwatora. Ten wzorzec umożliwia modelowi wysyłanie powiadomień o zmianach do wszystkich odbiorników. Jako detektor zdarzeń (lub obserwator) interfejs użytkownika otrzymuje powiadomienia i jest aktualizowany. Z jednej strony wzorzec obserwatora pozwala modelowi poinformować interfejs (widok i kontroler), że zaszły zmiany, nie wiedząc o tym nic, pozostając tym samym niezależnym. Z drugiej strony umożliwia synchronizację interfejsów użytkownika. musimy zaimplementować wzorzec obserwatora. Ten wzorzec umożliwia modelowi wysyłanie powiadomień o zmianach do wszystkich odbiorników. Jako detektor zdarzeń (lub obserwator) interfejs użytkownika otrzymuje powiadomienia i jest aktualizowany. Z jednej strony wzorzec obserwatora pozwala modelowi poinformować interfejs (widok i kontroler), że zaszły zmiany, nie wiedząc o tym nic, pozostając tym samym niezależnym. Z drugiej strony umożliwia synchronizację interfejsów użytkownika. musimy zaimplementować wzorzec obserwatora. Ten wzorzec umożliwia modelowi wysyłanie powiadomień o zmianach do wszystkich odbiorników. Jako detektor zdarzeń (lub obserwator) interfejs użytkownika otrzymuje powiadomienia i jest aktualizowany. Z jednej strony wzorzec obserwatora pozwala modelowi poinformować interfejs (widok i kontroler), że zaszły zmiany, nie wiedząc o tym nic, pozostając tym samym niezależnym. Z drugiej strony umożliwia synchronizację interfejsów użytkownika.
Krok 3 Podziel interfejs na widok i kontroler
Kontynuujemy dzielenie aplikacji na moduły, ale teraz na niższym poziomie w hierarchii. Na tym etapie interfejs użytkownika (który podzieliliśmy na oddzielny moduł w kroku 1) jest podzielony na widok i kontroler. Nakreślenie ścisłej granicy między widokiem a kontrolerem jest trudne. Jeśli powiemy, że widok jest tym, co widzi użytkownik, a kontroler jest mechanizmem, który pozwala użytkownikowi na interakcję z systemem, można wskazać sprzeczność. Elementy sterujące, takie jak przyciski na stronie internetowej czy wirtualna klawiatura na ekranie telefonu, są w zasadzie częścią kontrolera. Ale są one tak samo widoczne dla użytkownika jak dowolna część widoku. Tak naprawdę mówimy tutaj o separacji funkcjonalnej. Głównym zadaniem interfejsu użytkownika jest ułatwienie interakcji użytkownika z systemem.
wyjście i wygodne wyświetlanie informacji o systemie dla użytkownika
wprowadzać dane użytkownika i komendy (przekazywać je systemowi)
Funkcje te określają, w jaki sposób interfejs użytkownika powinien być podzielony na moduły. Ostatecznie architektura systemu wygląda tak: I tak dochodzimy do aplikacji składającej się z trzech modułów zwanych modelem, widokiem i kontrolerem. Podsumujmy:
Zgodnie z zasadami paradygmatu MVC system musi być podzielony na moduły.
Najważniejszym i niezależnym modułem powinien być model.
Model jest rdzeniem systemu. Powinna istnieć możliwość rozwijania i testowania go niezależnie od interfejsu użytkownika.
Aby to osiągnąć, w pierwszym kroku podziału musimy podzielić system na model i interfejs użytkownika.
Następnie za pomocą wzorca obserwatora wzmacniamy niezależność modelu i synchronizujemy interfejsy użytkownika.
Trzecim krokiem jest podzielenie interfejsu użytkownika na kontroler i widok.
Wszystko, co jest potrzebne do przyjęcia danych użytkownika do systemu, znajduje się w kontrolerze.
Wszystko, co jest potrzebne do dostarczania informacji użytkownikowi, znajduje się w widoku.
Jeszcze tylko jedna ważna rzecz do omówienia, zanim wypijesz gorącą czekoladę.
Trochę o interakcji widoku i kontrolera z modelem
Wprowadzając informacje poprzez kontroler, użytkownik zmienia model. Lub przynajmniej użytkownik zmienia dane modelu. Kiedy użytkownik otrzymuje informacje za pośrednictwem elementów interfejsu (poprzez widok), użytkownik otrzymuje informacje o modelu. Jak to się stało? W jaki sposób widok i kontroler wchodzą w interakcję z modelem? W końcu klasy widoku nie mogą bezpośrednio wywoływać metod klas modelu w celu odczytu/zapisu danych. Inaczej nie moglibyśmy powiedzieć, że model jest niezależny. Model jest zbiorem ściśle powiązanych klas, do których ani widok, ani kontroler nie powinny mieć dostępu. Aby połączyć model z widokiem i kontrolerem, musimy zaimplementować wzorzec projektowy elewacji. Fasada modelu to warstwa pomiędzy modelem a interfejsem użytkownika, za pośrednictwem którego widok otrzymuje wygodnie sformatowane dane, a Administrator zmienia dane wywołując niezbędne metody na elewacji. Ostatecznie wszystko wygląda tak:
MVC: Co zyskujemy?
Głównym celem paradygmatu MVC jest oddzielenie implementacji logiki biznesowej (model) od jej wizualizacji (widok). Ta separacja zwiększa możliwości ponownego użycia kodu. Korzyści z MVC są najbardziej widoczne, gdy musimy przedstawić te same dane w różnych formatach. Na przykład jako tabela, wykres lub wykres (przy użyciu różnych widoków). Jednocześnie, bez wpływu na sposób realizacji widoków, możemy zmieniać sposób, w jaki reagujemy na działania użytkownika (kliknięcia przycisków, wprowadzanie danych). Jeśli postępujesz zgodnie z zasadami MVC, możesz uprościć tworzenie oprogramowania, zwiększyć czytelność kodu oraz poprawić rozszerzalność i łatwość konserwacji. W ostatnim artykule z serii „Wprowadzenie do rozwoju przedsiębiorstwa” przyjrzymy się implementacji MVC zbudowanej przy użyciu Spring MVC. Część 8. Napiszmy małą aplikację z wykorzystaniem Spring Boot
W tym artykule poznamy coś, co nazywa się MVC. Porozmawiamy o tym, czym jest MVC, dotkniemy jego historii, zbadamy podstawowe idee i koncepcje zawarte w MVC, przyjrzymy się krok po kroku, jak podzielić aplikację na moduły Model, View i Controller, napiszemy małej aplikacji internetowej korzystającej z Spring Boot i na przykładzie Spring MVC zobaczyć, jak dane są przesyłane z kodu Java do stron HTML. Aby zrozumieć ten materiał, musisz znać wzorce projektowe, zwłaszcza obserwatora i elewacji. Zapoznaj się z żądaniami i odpowiedziami HTTP, zrozum podstawy języka HTML i dowiedz się, czym są adnotacje Java. Weź filiżankę kawy i przekąskę i usiądź wygodnie. Zaczynajmy.
Z tego wszystkiego możemy wyciągnąć logiczny wniosek. Złożony system należy podzielić na moduły. Opiszmy pokrótce kroki prowadzące do osiągnięcia tego rozdzielenia.
I tak dochodzimy do aplikacji składającej się z trzech modułów zwanych modelem, widokiem i kontrolerem. Podsumujmy:
