Wprowadzenie do architektury MVC
Najpopularniejszą architekturą aplikacji, którą zna każdy programista, jest MVC . MVC oznacza model-widok-kontroler .
To nie tyle architektura aplikacji, co architektura komponentów aplikacji, ale do tego niuansu wrócimy później. Co to jest MVC?
MVC to schemat rozdzielania danych aplikacji i logiki sterowania na trzy oddzielne komponenty — model, widok i kontroler — dzięki czemu każdy komponent może być modyfikowany niezależnie.
- Model (Model) dostarcza dane i odpowiada na polecenia kontrolera zmieniając swój stan.
- Widok jest odpowiedzialny za wyświetlanie danych modelu użytkownikowi w odpowiedzi na zmiany w modelu.
- Administrator (Kontroler) interpretuje działania użytkownika, powiadamiając model o potrzebie zmian.
Ten model został wynaleziony w 1978 (!) Roku. Tak, problemy z odpowiednią architekturą oprogramowania były istotne 50 lat temu. Oto jak ten model jest opisany na schemacie w oryginale:
Model udostępnia dane i metody pracy z nimi: zapytania do bazy danych, sprawdzanie poprawności. Model jest niezależny od widoku (nie wie, jak renderować dane) i kontrolera (nie ma punktów interakcji użytkownika), zapewniając dostęp do danych i zarządzanie nimi.
Model jest zbudowany w taki sposób, aby odpowiadać na żądania zmieniając swój stan, można też wbudować powiadamianie „obserwatorów”. Model, ze względu na niezależność od reprezentacji wizualnej, może mieć kilka różnych reprezentacji dla jednego „modelu”.
Widok odpowiada za pobranie wymaganych danych z modelu i przesłanie ich do użytkownika. Widok nie przetwarza danych wprowadzonych przez użytkownika.
Kontroler zapewnia „komunikację” między użytkownikiem a systemem. Kontroluje i kieruje dane od użytkownika do systemu i odwrotnie. Wykorzystuje model i widok do zaimplementowania żądanej akcji.
Pewną trudność sprawia fakt, że model ten ewoluował nieco na przestrzeni dziesięcioleci. Oznacza to, że nazwa pozostała taka sama, ale cel części zaczął się zmieniać.
Architektura MVC w sieci
Idea wzorca projektowego MVC jest bardzo prosta: musimy jasno rozdzielić odpowiedzialność za różne zachowania w naszych aplikacjach:
Model— przetwarzanie danych i logika aplikacji.
pogląd— udostępniania użytkownikowi danych w dowolnym obsługiwanym formacie.
kontroler- przetwarzanie żądań użytkowników i wywoływanie odpowiednich zasobów.
Aplikacja podzielona jest na trzy główne komponenty, z których każdy odpowiada za inne zadania. Przyjrzyjmy się bliżej komponentom aplikacji klient-serwer na przykładzie.
Kontroler
Użytkownik klika różne elementy na stronie w przeglądarce, w wyniku czego przeglądarka wysyła różne żądania HTTP: GET, POST lub inne. Kontroler może zawierać przeglądarkę oraz kod JS działający wewnątrz strony.
Główną funkcją kontrolera w tym przypadku jest wywoływanie metod na niezbędnych obiektach, zarządzanie dostępem do zasobów w celu wykonywania zadań określonych przez użytkownika. Zazwyczaj kontroler wywołuje odpowiedni model dla zadania i wybiera odpowiedni widok.
Model
Model w szerokim znaczeniu to dane i reguły, które służą do pracy z danymi - razem tworzą logikę biznesową aplikacji. Projektowanie aplikacji zawsze rozpoczyna się od zbudowania modeli obiektów, na których działa.
Powiedzmy, że mamy sklep internetowy, który sprzedaje książki, to czy osoba jest tylko użytkownikiem aplikacji, czy też autorem książki? Na te ważne pytania należy odpowiedzieć podczas projektowania modelu.
Ponadto istnieją zestawy zasad: co można, czego nie można zrobić, które zbiory danych są dopuszczalne, a które nie. Czy książka może istnieć bez autora? A autor bez książek? Czy data urodzenia użytkownika może być w roku 300 i tak dalej.
Model daje kontrolerowi widok danych, o które prosił użytkownik (wiadomość, strona książki, zdjęcia itp.). Model danych będzie taki sam bez względu na to, jak chcemy go przedstawić użytkownikowi. Dlatego do wyświetlania danych wybieramy dowolny dostępny widok.
Model zawiera najważniejszą część logiki naszej aplikacji , logikę rozwiązującą problem, z którym mamy do czynienia (forum, sklep, bank itp.). Kontroler zawiera głównie logikę organizacyjną dla samej aplikacji (podobnie jak Twój Project Manager).
Pogląd
Widok zapewnia różne sposoby reprezentowania danych otrzymanych z modelu. Może to być szablon wypełniony danymi. Może istnieć kilka różnych widoków, a kontroler wybiera, który z nich jest najlepszy w danej sytuacji.
Aplikacja internetowa zazwyczaj składa się z zestawu kontrolerów, modeli i widoków. Kontroler może znajdować się tylko na backendzie, ale może też istnieć wariant kilku kontrolerów, gdy jego logika jest rozłożona również na frontendzie. Dobrym przykładem takiego podejścia jest dowolna aplikacja mobilna.
Przykład MVC w sieci
Załóżmy, że musisz stworzyć sklep internetowy, który będzie sprzedawał książki. Użytkownik może wykonywać następujące czynności: przeglądać książki, rejestrować się, kupować, dodawać pozycje do aktualnego zamówienia, oznaczać książki, które mu się podobają oraz je kupować.
Twoja aplikacja powinna mieć model odpowiedzialny za całą logikę biznesową. Potrzebujesz również kontrolera , który będzie przetwarzał wszystkie działania użytkownika i zamieniał je w wywołania metod z logiki biznesowej. Jednak jedna metoda kontrolera może wywoływać wiele różnych metod modelowych.
Potrzebne są również zestawy widoków: lista książek, informacje o jednej książce, koszyk, lista zamówień. Każda strona aplikacji internetowej jest w rzeczywistości osobnym widokiem, który wyświetla użytkownikowi określony aspekt modelu.
Zobaczmy, co się stanie, jeśli użytkownik otworzy listę książek polecanych w księgarni, aby wyświetlić tytuły. Całą sekwencję działań można opisać w postaci 6 kroków:
Kroki:
- Użytkownik klika link „polecane”, a przeglądarka wysyła żądanie do, powiedzmy, /books/recommendations.
- Kontroler sprawdza żądanie : użytkownik musi być zalogowany. Albo powinniśmy mieć kolekcje książek dla niezalogowanych użytkowników. Kontroler następnie wywołuje model i prosi go o zwrócenie listy książek polecanych użytkownikowi N.
- Model uzyskuje dostęp do bazy danych, pobiera z niej informacje o książkach: książki, które są aktualnie popularne, książki kupione przez użytkownika, książki kupione przez jego znajomych, książki z jego listy życzeń. Na podstawie tych danych model buduje listę 10 polecanych książek i zwraca je do kontrolera.
- Kontroler otrzymuje listę polecanych książek i przegląda ją. Na tym etapie to kontroler podejmuje decyzje! Jeśli jest mało książek lub lista jest całkowicie pusta, żąda listy książek dla niezalogowanego użytkownika. Jeśli w tej chwili trwa promocja, administrator może dodać do listy książki promocyjne.
- Kontroler określa, którą stronę pokazać użytkownikowi. Może to być strona błędu, strona z listą książek, strona z gratulacjami, że użytkownik został milionowym gościem.
- Serwer przekazuje klientowi wybraną przez kontrolera stronę ( widok ). Jest uzupełniany niezbędnymi danymi (nazwa użytkownika, lista książek) i trafia do klienta.
- Klient otrzymuje stronę i wyświetla ją użytkownikowi.
Jakie są korzyści z tego podejścia?
Najbardziej oczywistą zaletą, jaką uzyskujemy dzięki zastosowaniu koncepcji MVC, jest wyraźne rozdzielenie logiki prezentacji (interfejs użytkownika) i logiki aplikacji (backend).
Drugą zaletą jest podział części serwerowej na dwie części: model smart ( executor ) oraz kontroler ( centrum decyzyjne ).
W poprzednim przykładzie był moment, kiedy kontroler mógł otrzymać od modelu pustą listę polecanych książek i zdecydować, co z nią zrobić. Teoretycznie tę logikę można umieścić bezpośrednio w modelu.
Po pierwsze, prosząc o polecane książki, model decydowałby, co zrobić, jeśli lista jest pusta. Wtedy musiałbym dodać kod w tym samym miejscu, co zrobić, jeśli teraz trwa promocja, a potem więcej różnych opcji.
Potem okazało się, że administrator sklepu chciał zobaczyć, jak będzie wyglądać strona użytkownika bez promocji, lub odwrotnie, teraz nie ma promocji, ale chce zobaczyć, jak będzie wyświetlana przyszła promocja. I nie ma na to żadnych metod. Dlatego zdecydowano się na oddzielenie centrum decyzyjnego (kontrolera) od logiki biznesowej (model).
Oprócz izolowania widoków od logiki aplikacji, koncepcja MVC znacznie zmniejsza złożoność dużych aplikacji. Kod jest znacznie bardziej uporządkowany, co ułatwia konserwację, testowanie i ponowne wykorzystywanie rozwiązań.
Rozumiejąc koncepcję MVC, jako programista zdajesz sobie sprawę, gdzie musisz dodać sortowanie listy książek:
- Na poziomie zapytania do bazy danych.
- Na poziomie logiki biznesowej (model).
- Na poziomie logiki biznesowej (kontroler).
- W widoku - po stronie klienta.
I nie jest to pytanie retoryczne. Już teraz zastanów się, gdzie i dlaczego musisz dodać kod do sortowania listy książek.
Klasyczny model MVC
Interakcja między komponentami MVC jest realizowana inaczej w aplikacjach internetowych i aplikacjach mobilnych. Dzieje się tak, ponieważ aplikacja internetowa jest krótkotrwała, przetwarza jedno żądanie użytkownika i kończy działanie, podczas gdy aplikacja mobilna przetwarza wiele żądań bez ponownego uruchamiania.
Aplikacje internetowe zazwyczaj korzystają z modelu „pasywnego”, podczas gdy aplikacje mobilne korzystają z modelu „aktywnego”. Model aktywny w przeciwieństwie do pasywnego umożliwia subskrypcję i otrzymywanie powiadomień o zmianach w nim. Nie jest to wymagane w przypadku aplikacji internetowych.
Tak wygląda interakcja komponentów w różnych modelach:
Aplikacje mobilne (model aktywny) aktywnie wykorzystują zdarzenia i mechanizm subskrypcji zdarzeń. Przy takim podejściu widok ( widok ) subskrybuje zmiany modelu. Następnie, gdy wystąpi jakieś zdarzenie (na przykład użytkownik kliknie przycisk), kontroler nazywa się . Daje również modelowi polecenie zmiany danych.
Jeśli jakieś dane uległy zmianie, to model generuje zdarzenie o zmianie tych danych. Wszystkie widoki, które zasubskrybowały to zdarzenie (dla których ważna jest zmiana tych konkretnych danych) odbierają to zdarzenie i aktualizują dane w swoim interfejsie.
W aplikacjach internetowych wszystko jest zorganizowane trochę inaczej. Główna różnica techniczna polega na tym, że klient nie może odbierać wiadomości po stronie serwera z inicjatywy serwera .
Dlatego kontroler w aplikacji webowej zwykle nie wysyła żadnych komunikatów do widoku, ale daje klientowi nową stronę, która jest technicznie nowym widokiem lub nawet nową aplikacją kliencką (jeśli jedna strona nic nie wie o drugiej) .
Obecnie problem ten jest częściowo rozwiązany za pomocą następujących podejść:
- Regularne sondowanie serwera pod kątem zmian ważnych danych (raz na minutę lub częściej).
- WebSockets umożliwiają klientowi subskrybowanie wiadomości serwera.
- Powiadomienia web push od strony serwera.
- Protokół HTTP/2 umożliwia serwerowi zainicjowanie wysyłania wiadomości do klienta.