Czym tak naprawdę jest MVC?

Jako poważny programista, jak odpowiesz na pytanie Co to jest MVC?

Moim zdaniem, MVC jest dość mglistym tematem - dlatego też, jeśli twoja publiczność jest uczniem, możesz opisać go w kategoriach ogólnych, które raczej nie będą kontrowersyjne.

Jeśli jednak rozmawiasz ze znającą się na rzeczy publicznością, a zwłaszcza z ankieterem, trudno mi się zastanowić nad wyborem kierunku, który nie ryzykuje reakcji „no cóż, to nie w porządku! ...”. Wszyscy mamy różne doświadczenia w świecie rzeczywistym i nigdy nie spotkałem się dwukrotnie z tym samym wzorcem implementacji MVC.

W szczególności wydaje się, że istnieją spory dotyczące ścisłości, definicji komponentu, oddzielenia części (jaki kawałek pasuje gdzie) itp.

Jak mam wyjaśnić MVC w sposób poprawny, zwięzły i niekontrowersyjny?

MVC to architektura oprogramowania - struktura systemu - która oddziela logikę domeny / aplikacji / biznesu (cokolwiek wolisz) od reszty interfejsu użytkownika. Odbywa się to poprzez podzielenie aplikacji na trzy części: model, widok i kontroler.

Model zarządza podstawowymi zachowaniami i danymi aplikacji. Może odpowiadać na prośby o informacje, odpowiadać na instrukcje zmiany stanu informacji, a nawet powiadamiać obserwatorów w systemach sterowanych zdarzeniami o zmianie informacji. Może to być baza danych lub dowolna liczba struktur danych lub systemów pamięci. Krótko mówiąc, są to dane i zarządzanie danymi aplikacji.

Widok skutecznie zapewnia element interfejsu użytkownika aplikacji. Wyrenderuje dane z modelu w formie odpowiedniej dla interfejsu użytkownika.

Kontroler odbiera dane wejściowe od użytkownika i wywołuje modele obiektów oraz widok w celu wykonania odpowiednich działań.

Podsumowując, te trzy komponenty współpracują ze sobą, tworząc trzy podstawowe komponenty MVC.

Analogia

Wyjaśniłem MVC mojemu tacie w ten sposób:

MVC (model, widok, kontroler) to wzorzec organizowania kodu w aplikacji w celu poprawy możliwości konserwacji.

Wyobraź sobie fotografa z aparatem w studio. Klient prosi go o zrobienie zdjęcia pudełka.

Pudełko to model , fotograf to kontroler, a aparat to widok .

Ponieważ pudełko nie zna aparatu ani fotografa, jest całkowicie niezależne. Ta separacja pozwala fotografowi na obejście pudełka i skierowanie aparatu pod dowolnym kątem, aby uzyskać pożądane ujęcie / widok.

Architektury inne niż MVC są ze sobą ściśle zintegrowane. Gdyby więc pudełko, kontroler i kamera były jednym i tym samym obiektem, musielibyśmy rozdzielić, a następnie przebudować zarówno pudełko, jak i kamerę za każdym razem, gdy chcieliśmy uzyskać nowy widok. Robienie zdjęcia zawsze byłoby jak próba zrobienia selfie - i to nie zawsze jest bardzo łatwe.

Szczegółowe wyjaśnienie

Dopiero po przeczytaniu następującego pytania / odpowiedzi maillisty poczułem, że rozumiem MVC. Cytat: https://mail.python.org/pipermail/python-list/2006-J stycznia/ 394968.html

bwaha napisał:

Autor odwołuje się do mvctree.py w wxPython jako przykład projektu MVC. Jednak wciąż jestem zbyt zielony, więc uważam ten konkretny przykład za zbyt złożony i nie rozumiem podziału, który autor zaleca.

W MVC chodzi o rozdzielenie obaw.

Model odpowiada za zarządzanie danymi programu (zarówno danymi prywatnymi, jak i klientami). View / Controller odpowiada za zapewnienie światu zewnętrznemu środków do interakcji z danymi klienta programu.

Model zapewnia wewnętrzny interfejs (API) umożliwiający interakcję z innymi częściami programu. Widok / Kontroler zapewnia zewnętrzny interfejs (GUI / CLI / formularz internetowy / wysokopoziomowy IPC / itp.), Aby umożliwić wszystkim programom komunikację z nim.

Model jest odpowiedzialny za utrzymanie integralności danych programu, ponieważ jeśli zostanie to uszkodzone, to gra jest skończona dla wszystkich. Widok / Kontroler jest odpowiedzialny za utrzymanie integralności interfejsu użytkownika, upewnienie się, że wszystkie widoki tekstu wyświetlają aktualne wartości, wyłączenie elementów menu, które nie dotyczą bieżącego fokusa itp.

Model nie zawiera kodu widoku / kontrolera; bez klas widżetów GUI, bez kodu do układania okien dialogowych lub otrzymywania danych wejściowych od użytkownika. Widok / kontroler nie zawiera kodu modelu; brak kodu do sprawdzania poprawności adresów URL lub wykonywania zapytań SQL, a także brak stanu oryginalnego: wszelkie dane przechowywane przez widżety służą wyłącznie do wyświetlania, a jedynie odzwierciedlenie prawdziwych danych przechowywanych w Modelu.

Oto test prawdziwego projektu MVC: program powinien zasadniczo być w pełni funkcjonalny, nawet bez dołączonego View / Controller. OK, świat zewnętrzny będzie miał problem z interakcją z nim w tej formie, ale dopóki znamy odpowiednie inkantacje Model API, program będzie przechowywał i manipulował danymi w normalny sposób.

Dlaczego to jest możliwe? Cóż, prosta odpowiedź jest taka, że ​​wszystko dzięki niskiemu sprzężeniu między warstwami Model i View / Controller. To jednak nie jest pełna historia. Kluczem do całego wzorca MVC jest kierunek, w którym podąża to połączenie: WSZYSTKIE instrukcje przepływają z widoku / kontrolera do modelu. Model NIGDY nie mówi View / Controller, co ma robić.

Dlaczego? Ponieważ w MVC, podczas gdy widok / kontroler może trochę wiedzieć o modelu (w szczególności API modelu), ale model nie może nic wiedzieć o widoku / kontrolerze.

Dlaczego? Ponieważ MVC polega na stworzeniu wyraźnego podziału obaw.

Dlaczego? Aby zapobiec złożoności programu wymykającej się spod kontroli i zakopaniu pod nim dewelopera. Im większy program, tym większa liczba komponentów w tym programie. Im więcej połączeń istnieje między tymi komponentami, tym trudniej jest programistom utrzymać / rozszerzyć / wymienić poszczególne komponenty, a nawet po prostu śledzić działanie całego systemu. Zadaj sobie to pytanie: czy patrząc na schemat struktury programu wolisz zobaczyć drzewo lub kołyskę kota? Wzorzec MVC unika tego drugiego, uniemożliwiając połączenia okrągłe: B może połączyć się z A, ale A nie może połączyć się z B. W tym przypadku A jest modelem, a B jest widokiem / kontrolerem.

BTW, jeśli jesteś bystry, zauważysz problem z właśnie opisanym ograniczeniem „jednokierunkowym”: w jaki sposób Model może informować Widok / Kontroler o zmianach w danych użytkownika Modelu, gdy Modelowi nie wolno nawet wiesz, że widok / kontroler, nie wspominając o wysyłaniu do niego wiadomości? Ale nie martw się: istnieje na to rozwiązanie i jest to całkiem fajne, nawet jeśli na początku wydaje się nieco ronda. Wrócimy do tego za chwilę.

W praktyce zatem obiekt View / Controller może, poprzez interfejs API Modelu, 1. powiedzieć Modelowi, aby zrobił rzeczy (wykonać polecenia) i 2. powiedzieć Modelowi, aby dał mu rzeczy (dane zwrotne). Warstwa Widok / Kontroler wypycha instrukcje do warstwy Model i pobiera informacje z warstwy Model.

I właśnie tam twój pierwszy przykład MyCoolListControl poszedł nie tak, ponieważ API dla tej klasy wymaga, aby informacje zostały wepchnięte do niej, więc wróciłeś do dwukierunkowego łączenia między warstwami, naruszając reguły MVC i wrzucając cię z powrotem do architektura kołyski kota, której [prawdopodobnie] starałeś się przede wszystkim uniknąć.

Zamiast tego klasa MyCoolListControl powinna iść z przepływem, wyciągając potrzebne dane z warstwy poniżej, gdy tego potrzebuje. W przypadku widżetu listy oznacza to na ogół pytanie o liczbę wartości, a następnie pytanie o każdy z tych elementów po kolei, ponieważ jest to najprostszy i najbardziej luźny sposób, aby to zrobić, a zatem ogranicza do minimum to, co istnieje. A jeśli widget chce, powiedzmy, przedstawić te wartości użytkownikowi w ładnej kolejności alfabetycznej, to jest to przesadzone; i oczywiście jego odpowiedzialność.

A teraz ostatnia zagadka, jak już wcześniej wspomniałem: jak utrzymać synchronizację ekranu interfejsu użytkownika ze stanem Modelu w systemie opartym na MVC?

Oto problem: wiele obiektów View ma charakter stanowy, np. Pole wyboru może być zaznaczone lub odznaczone, pole tekstowe może zawierać tekst edytowalny. Jednak MVC nakazuje, aby wszystkie dane użytkownika były przechowywane w warstwie modelu, więc wszelkie dane przechowywane przez inne warstwy do celów wyświetlania (stan pola wyboru, aktualny tekst pola tekstowego) muszą zatem być kopią pomocniczą tych podstawowych danych modelu. Ale jeśli stan modelu zmieni się, kopia tego stanu widoku nie będzie już dokładna i należy ją odświeżyć.

Ale jak? Wzorzec MVC uniemożliwia Modelowi wypchnięcie świeżej kopii tej informacji do warstwy Widok. Do licha, nawet nie pozwala modelowi wysłać widoku Zobacz, że jego stan się zmienił.

Cóż prawie. Okej, warstwa Modelu nie może rozmawiać bezpośrednio z innymi warstwami, ponieważ wymagałoby to znajomości tych warstw, a reguły MVC temu zapobiegają. Jeśli jednak drzewo spada w lesie i nikt go nie słyszy, czy wydaje to dźwięk?

Widzisz, odpowiedzią jest skonfigurowanie systemu powiadomień, zapewniającego warstwie modelu miejsce, w którym nikt nie będzie w stanie ogłosić, że właśnie zrobił coś interesującego. Inne warstwy mogą następnie wysyłać słuchaczy za pomocą tego systemu powiadomień, aby nasłuchiwać ogłoszeń, którymi są faktycznie zainteresowani. Warstwa Model nie musi wiedzieć nic o tym, kto słucha (a nawet jeśli ktoś w ogóle słucha!); po prostu publikuje ogłoszenie, a następnie zapomina o tym. A jeśli ktoś usłyszy to ogłoszenie i poczuje ochotę zrobić coś później - na przykład poprosić Modelkę o nowe dane, aby mógł zaktualizować wyświetlanie na ekranie - to świetnie. Model zawiera tylko listę powiadomień, które wysyła jako część definicji API; i to, co ktokolwiek robi z tą wiedzą, zależy od nich.

MVC zostało zachowane i wszyscy są zadowoleni. Struktura aplikacji może równie dobrze zapewniać wbudowany system powiadomień, lub możesz napisać własny, jeśli nie (patrz „wzorzec obserwatora”).

...

W każdym razie, mam nadzieję, że to pomaga. Kiedy zrozumiesz motywacje stojące za MVC, powody, dla których rzeczy są robione tak, jak są, zaczynają mieć sens, nawet gdy - na pierwszy rzut oka - wydają się bardziej złożone niż to konieczne.

Twoje zdrowie,

ma

MVC to w większości modne słowo.

Kiedyś uważano go za wzór, ale jego pierwotna definicja z 1979 r. Została stępiona, przekazana, źle zinterpretowana, wyjęta z kontekstu oryginalnego. Zostało źle zdefiniowane do tego stopnia, że ​​zaczyna przypominać religię, i chociaż z pewnością pomaga to kultystom ładunku broniącym go, jego nazwa nie kojarzy się już z solidnym zbiorem wytycznych . Jako taki nie można już tak naprawdę traktować go za wzór.

MVC nigdy nie miało opisywać aplikacji internetowych.
Ani nowoczesne systemy operacyjne, ani języki.
(niektórzy z nich faktycznie zwolnili definicję z 1979 r.)

Zostało to zrobione. I to nie wyszło.

Mamy teraz do czynienia z nieprzyzwoitą hybrydą web-mvc, która ze swoim okropnym hasłem, złą definicją i posiadaniem częściowo niepiśmiennych programistów jako docelowej grupy demograficznej sprawia, że ​​ogólnie bardzo źle reklamuje się wzorce oprogramowania.

Tak więc MVC stało się oddzieleniem destylowanych obaw dla osób, które tak naprawdę nie chcą za dużo o tym myśleć.

• Model danych jest obsługiwany w jedną stronę,
• widok w innym,
• reszta została po prostu nazwana „kontrolerem” i pozostawiona do uznania czytelnika.

Witryny internetowe / aplikacje internetowe w latach 90. tak naprawdę nie używały rozdzielania problemów.

To były okropne bzdury wymieszanego kodu spaghetti.
Zmiany interfejsu użytkownika, przeprojektowania i zmiany układu danych były niewiarygodnie trudne, drogie, długie, przygnębiające i niefortunne.

Technologie sieciowe, takie jak ASP, JSP i PHP, zbyt łatwo łączą problemy dotyczące widoku z danymi i obawami dotyczącymi aplikacji. Nowicjusze w tej branży zwykle emitują nierozerwalne błotniki kodu, jak w dawnych czasach.

W ten sposób rosnąca liczba osób zaczęła powtarzać „używaj MVC” w niekończących się pętlach na forach wsparcia. Liczba osób wzrosła do tego stopnia, że ​​obejmowała menedżerów i marketerów (do niektórych termin ten był już znany, od czasów programowania GUI, w których wzorzec miał sens), i stało się ono potworem modnego hasła, z którym musimy się teraz zmierzyć .

W obecnej formie jest to zdrowy rozsądek , a nie metodologia .
To punkt wyjścia , a nie rozwiązanie .
To tak, jakby kazać ludziom oddychać powietrzem lub robić brzuszki , a nie lekarstwo na raka .

Najlepszym sposobem na zdefiniowanie tego jest przejście do oryginalnych pism Trygve'a Reenskauga , który go wynalazł: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

W szczególności ten dokument jest ogólnie uważany za tekst definicyjny: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

MODELE

Modele reprezentują wiedzę. Model może być pojedynczym obiektem (raczej nieciekawym) lub może być jakąś strukturą obiektów ...

Powinna istnieć korespondencja jeden-do-jednego między modelem i jego częściami z jednej strony, a światem reprezentowanym postrzeganym przez właściciela modelu z drugiej strony. Węzły modelu powinny zatem stanowić możliwą do zidentyfikowania część problemu.

Węzły modelu powinny znajdować się na tym samym poziomie problemu, jest mylące i uważane za zły sposób mieszania węzłów problemowych (np. Terminów kalendarza) ze szczegółami implementacji (np. Akapitami).

WYŚWIETLENIA

Widok jest (wizualną) reprezentacją jego modelu. Zwykle podkreślałby niektóre atrybuty modelu i tłumił inne. Działa zatem jako filtr prezentacji .

Widok jest dołączony do jego modelu (lub części modelu) i pobiera dane niezbędne do prezentacji z modelu, zadając pytania. Może również zaktualizować model, wysyłając odpowiednie wiadomości. Wszystkie te pytania i komunikaty muszą być w terminologii modelu, dlatego widok będzie musiał znać semantykę atrybutów modelu, który reprezentuje. (Może na przykład prosić o identyfikator modelu i oczekiwać wystąpienia tekstu, nie może zakładać, że model jest klasy tekstu).

STEROWNIKI

Kontroler to połączenie między użytkownikiem a systemem. Zapewnia użytkownikowi wkład, organizując odpowiednie widoki, aby zaprezentować się w odpowiednich miejscach na ekranie. Zapewnia środki dla wyników użytkownika poprzez prezentowanie użytkownikowi menu lub innych sposobów wydawania poleceń i danych. Kontroler odbiera takie dane wyjściowe użytkownika, tłumaczy je na odpowiednie komunikaty i przekazuje te wiadomości do jednego lub więcej widoków.

Kontroler nigdy nie powinien uzupełniać widoków, na przykład nigdy nie powinien łączyć widoków węzłów poprzez rysowanie strzałek między nimi.

I odwrotnie, widok nigdy nie powinien wiedzieć o danych wejściowych użytkownika, takich jak operacje myszy i naciśnięcia klawiszy. Zawsze powinna istnieć możliwość napisania metody w kontrolerze, która wysyła komunikaty do widoków, które dokładnie odtwarzają dowolną sekwencję poleceń użytkownika.

REDAKCJE

Kontroler jest podłączony do wszystkich jego widoków, nazywane są częściami kontrolera. Niektóre widoki zapewniają specjalny kontroler, edytor , który pozwala użytkownikowi modyfikować informacje prezentowane przez widok. Takie edytory mogą zostać połączone w ścieżkę między kontrolerem a jego widokiem i będą działać jako rozszerzenie kontrolera. Po zakończeniu procesu edycji edytor jest usuwany ze ścieżki i odrzucany.

Zauważ, że edytor komunikuje się z użytkownikiem za pomocą metafor połączonego widoku, dlatego jest on ściśle powiązany z widokiem. Kontroler przejmie edytor, pytając o widok - nie ma innego odpowiedniego źródła.

MVC to wzorzec projektowy używany do izolowania logiki biznesowej od prezentacji.

Różni się od wielu innych wzorców projektowych tym, że zwykle nie jest zaimplementowany zwięźle, ale jest podstawą frameworka.

Podczas gdy aplikacja implementująca wzorzec strategii jest tylko niewielkim szczegółem na ten temat, stwierdzenie, że aplikacja internetowa korzysta ze wzorca projektowego MVC, bardzo definiuje jego architekturę .

MVC to projekt oprogramowania, który oddziela następujące elementy systemu lub podsystemu:

1. Model - dane o stanie aplikacji lub jej składników. Może zawierać procedury modyfikacji lub dostępu.
2. Widok - interpretacja danych (model). Jest to ograniczone tylko do przedstawienia wizualnego, ale może to być dźwięk, informacje pochodne (np. Statystyki połączone z innym obiektem modelu), itp. Ponadto pojedynczy model może mieć wiele widoków.
3. Sterowanie - obsługuje zewnętrzne dane wejściowe do systemu wywołujące modyfikacje modelu. Kontrola / widok może być ściśle powiązany (w przypadku interfejsu użytkownika). Można jednak przetwarzać inne zewnętrzne dane wejściowe (takie jak polecenia sieciowe), które są całkowicie niezależne od widoku.

Powiedziałbym, że MVC to koncepcja lub rodzina podobnych wzorów.

Myślę, że ten artykuł warto przeczytać. Architektury GUI autorstwa Martina Fowlera

Najpierw musisz ustalić, kto jest pytającym i jakiego rodzaju odpowiedzi szuka. Odpowiadasz na to pytanie innym pytaniem, na przykład „W jakim sensie?”

Możesz zapytać, czy odnoszą się one ogólnie do MVC, konkretnej implementacji MVC (tj. Asp.net MVC, spring MVC, smalltalk MVC itp.), Co to jest technicznie, co to jest filozoficzne (tak, ma także filozofia) itp.

Jeśli jest to pytanie w teście i nie możesz poprosić pytającego o wyjaśnienie, będziesz musiał zgadywać na podstawie kontekstu.

Dobra, prosta odpowiedź to:

MVC to architektura interfejsu użytkownika oprogramowania używana do oddzielania problemów strukturalnych i behawioralnych w celu ułatwienia łatwiejszego do utrzymania oprogramowania.

Możesz też powiedzieć:

Oddzielając widok od kontrolera od modelu, zachęca do izolacji komponentów w oparciu o ich obowiązki. Teoretycznie i zwykle w praktyce pomaga to poprawić łatwość konserwacji, zapobiegając mieszaniu się różnych części systemu i tworząc bardziej złożone systemy.

Ale ostatecznie zostaniesz osądzony na podstawie tego, czy dasz odpowiedź, której oczekują. Jedynym rozwiązaniem tego problemu jest ustalenie, jakiej odpowiedzi oczekują.

Oto, co bym o tym powiedział. Chciałbym wyjaśnić to w kategoriach aplikacji mobilnych, ponieważ to jest to, co znam najbardziej i ponieważ nie sądzę, że w pełni to zrozumiałem, zanim zacząłem tworzyć aplikacje mobilne.
Weźmy na przykład Androida.
Warstwa prezentacji, tj. interfejs użytkownika może (powinien, najczęściej jest) być całkowicie określony w formacie xml. Dla uproszczenia załóżmy, że jeden plik xml opisuje jeden ekran w aplikacji. Plik XML określa elementy sterujące, układ elementów sterujących, położenie, kolory, rozmiar, etykiety ciągów ... wszystko, co dotyczy prezentacji. Jednak nie wie nic o tym, kiedy zostanie wywołany, kiedy zostanie umieszczony na ekranie. Czy będzie to samodzielny układ czy część większego układu? Masz to: Twój idealny WIDOK .

Teraz widok w pewnym momencie musi zostać umieszczony na ekranie, więc jak to zrobić? Twój KONTROLER w systemie Android o nazwie Aktywność. Jak sama nazwa wskazuje, aktywność wykonuje pewną aktywność. Nawet jeśli jego jedynym celem jest wyświetlenie widoku zdefiniowanego w kroku 1, wykona on pewną akcję. Tak więc aktywność pobiera widok i wyświetla go na ekranie. Ponieważ widok nie wie nic o aktywności, podobnie aktywność nie wie nic o rzeczywistej prezentacji. My (programiści) mogliśmy wielokrotnie zmieniać układ widoku, nie zmieniając nawet jednego wiersza kodu w naszej działalności.

Teraz nie ma większego sensu prezentowanie ładnego, błyszczącego, dobrze zdefiniowanego układu xml bez robienia czegoś. Powiedzmy, że chcemy przechowywać dane wprowadzone przez użytkownika. Aktywność musi poradzić sobie z tym procesem, od zabrania danych od użytkownika do przekazania go komuś innemu, aby go obsłużył (przetwarzaj, przechowuj, usuwaj). Komu to przejdzie? Cóż, do MODELU . Lubię myśleć o modelu jako czystym. klasa java, która nie wie nic o kontekście aplikacji, w której żyje. (W praktyce prawie nigdy tak nie będzie).

Powiedzmy, że mam klasę Osoba, która ma trzy właściwości: imię, adres, wiek. Mój układ XML ma 3 pola do wprowadzenia przez użytkownika: imię i nazwisko, adres, wiek. Moja aktywność pobiera trzy wartości z danych wejściowych użytkownika, tworzy nowy obiekt Person i wywołuje na nim metodę, która wie, jak obsługiwać logikę specyficzną dla Person. Masz to. Model-View-Controller.

Zawsze zaczynam od powiedzenia im, że wzór nie jest niczym nowym i istnieje od wielu lat ... w tym momencie dają mi ciekawy wygląd i BAM !, są uzależnieni:

I wtedy prawie mówiłbym o różnych punktach, takich jak poprzednie odpowiedzi, ale myślę, że ważne jest, aby być kontekstowym, jak powiedział JB King, ASP.NET MVC itp.