Jaki jest właściwy schemat MVC dla aplikacji webowej?

MVC, ściśle mówiąc, jest rodzajem przestarzałego wzorca. Mówiąc gruboziarnisto, wprowadza zależności między widokiem a modelem, ponieważ Model aktualizuje status widoku bezpośrednio ( http://www.mimuw.edu.pl / ~sl/teaching/00_01/Delfin_EC/Overviews/MVC.htm), Jak pokazano na diagramie 4, gdzie widać bezpośrednie interakcje między modelem a widokiem, zgodnie z oryginalnym, historycznym sformułowaniem MVC, a to nie jest pożądane. W rzeczywistości, dzisiaj mamy zmodyfikowane wersje MVC, a czasami opisujemy MVP i nazwij to MVC. Akronim " MVC " został użyty z tak dużą swobodą, że wszystko, gdzie masz trzy elementy zwane modelem, widokiem i kontrolerem, jest w zasadzie MVC, pomimo szczegółów implementacji i definicji odpowiedzialności. Różnica jest naprawdę subtelna między MVC i MVP, kiedy je opisujesz, i polega na definicji obowiązków View i Presenter (Controller). Martin Fowler pożegnał MVP (i MVC) kilka lat temu ( http://www.martinfowler.com/eaaDev/ModelViewPresenter.html ), a z jego strony możemy znaleźć definicję "nowego" wzorca zwanego modelem prezentacji (patrz http://martinfowler.com/eaaDev/PresentationModel.html ), lub PM. Microsoft zdefiniował dla swoich technologii WPF i Silverlight inny wzór, zwany Model-View-View-Presenter lub MVVM (zobacz http://msdn.microsoft.com/en-us/magazine/dd419663.aspx ), który ma Model prezentacji jako swoją inspirację. Myślę, że ty można spojrzeć na tych wszystkich facetów i dowiedzieć się, jak bardzo podobne (i różne) są. Moim skromnym zdaniem, podstawową ideą jest to, że dane i zachowanie prezentacji pozostają w prezenterze, Model nie zna widoku (więc diagram 4 jest wyłączony, nawet będąc MVC) i powinieneś być w stanie zmienić widok (lub obsługiwać różne implementacje widoku) w bezbolesny sposób, oddzielony zarówno od prezentera, jak i modelu. Model prezentacji może to zapewnić i jest skuteczny i dokładny do wdrożenia przy użyciu aktualnych technologie.

W rzeczywistości jest mała różnica.

Istnieją dwa typy modeli: Model aktywny i model pasywny: pierwszy z nich ma mechanizm powiadamiania, a drugi nie jest po prostu nieświadomy użycia w MVC.

Pierwszy i czwarty diagram przedstawiają MVC z aktywnym modelem.

Więcej na ten temat można przeczytać tutaj .

Diagramy 1 i 4 są poprawnymi wzorcami MVC. Reszta jest bliższa wzorcowi MVP.

Chociaż w Web MVC masz pasywny Model i zmiany są ciągnięte przez Widok Z modelu, zamiast być popychane przez Model (wzorzec obserwatora ).

Żaden z nich nie jest w rzeczywistości zły, ale istnieje inne podejście do MVC opartego na web (request/response) i MVC po stronie klienta.

W środowisku webowym kontroler jest odpowiedzialny za obsługę żądania użytkownika, modyfikację modelu (jeśli dotyczy), znalezienie odpowiedniego widoku, przypisanie informacji o modelu do widoku i zwrócenie go użytkownikowi.

W bardziej bezpośredniej interpretacji oryginalnego wzorca MVC (speak desktop applications) model aktualizuje widok bezpośrednio, za każdym razem, gdy się zmienia, a kontroler zajmuje się wprowadzaniem przez użytkownika i logiką aplikacji, odpowiednio aktualizując model. Nie działa to jednak w przypadku zwykłych aplikacji internetowych, ponieważ HTTP jest bezpaństwowy i bez użycia jakiejkolwiek innej nowszej technologii (jak long polling Ajax lub websockets, jak wspomniano w komentarzu) serwer nie może tak naprawdę powiadomić klienta o zmianach w modelu.

Diagramy 2, 3 i 5 są dokładne dla MVC. Po wysłaniu żądania do kontrolera wykonuje on operację za pomocą modeli, a następnie odpowiada.

Diagram 1 jest prawidłowym odwzorowaniem wzorca MVC.

Linie stałe reprezentują rzeczywiste odniesienie, jak w zmiennej. Oznacza to, że należy spodziewać się wystąpienia modelu zarówno w widoku, jak i w kontrolerze.

Linie przerywane reprezentują wywołania funkcji lub wiadomości między sobą. Przerywana linia od modelu do widoku jest zaimplementowana za pomocą wzorca Observer, gdzie coś się zmieniło na modelu i ma odniesienie do widoku (poprzez API obserwatora modelu), gdzie wywołuje na nim metodę. Coś w rodzaju observer[i].update("name", value, self), które będzie wywoływane w modelu, gdy coś się zmieni.

Przerywana linia pomiędzy widokiem a kontrolerem to Widok wysyłający wiadomość do kontrolera. Wyobraź sobie przycisk w interfejsie użytkownika, który został kliknięty. Kontroler nasłuchuje tego zdarzenia i obsługuje je.

Przykładem przepływu komunikacji będzie kliknięcie przycisku: View wysyła wiadomość do kontrolera. Kontroler obsługuje, że zdarzenie, gdzie aktualizuje instancję modelu, powiedzmy model.name. Model posiada metodę setter, która aktualizuje name i wywołuje metodę podobną do changed, która następnie zapętla obserwatorów i wywołuje .update na każdym obserwatorze. Widok poprzednio subscribed do modelu i zostanie wywołany update ze starymi i nowymi wartościami name. Metoda update w widoku aktualizuje wartość nazwy w label. Załatwione.

Slide deck opisujący MVC: https://pl.csie.ntut.edu.tw/ ~ ctchen / pdf / InsideSmalltalkMVC-public. pdf

C2 Wiki MVC artykuł: http://wiki.c2.com/?ModelViewController