Ten materiał jest częścią serii „Wprowadzenie do rozwoju przedsiębiorstwa”. Poprzednie artykuły:
- o sieciowaniu
- o architekturze oprogramowania
- o HTTP/HTTPS
- o podstawach Mavena
- o serwletach (pisanie prostej aplikacji internetowej)
- o kontenerach serwletów
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
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
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)
- 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.
GO TO FULL VERSION