Czy kontroler powinien przekazać dane do widoku we wzorze MVC?

Często korzystam z ASP.NET MVC (i innych implementacji MVC opartych na sieci), ale nigdy nie byłem tego pewien: czy kontroler i widok powinny się komunikować?

Oczywiście administrator powinien wybrać, którego widoku użyć, ale o co mi chodzi, czy powinien przekazywać dane do tego widoku? Moim zdaniem, jeśli widok oczekuje danych od kontrolera, to są one skutecznie powiązane ze sobą jako para (kontroler, widok). Zamiast tego zazwyczaj mam widok komunikujący się z samym modelem i niezależny od jakiegokolwiek kontrolera.

Czy mam właściwe podejście, czy jest to przypadek braku jednej poprawnej odpowiedzi? Czy odpowiedź zmienia się podczas pracy w sieci w porównaniu do innych środowisk? Czy odpowiedź zmienia się, gdy masz pojęcie silnie typowanego widoku (jak w ASP.NET MVC), czy nie?

Kontroler przygotowuje dane, które następnie zostaną przekazane do widoku w celu renderowania / wyświetlania. Akceptuje również dane wejściowe użytkownika za pośrednictwem mechanizmu publikowania-subskrybowania lub podobnego. Sprawdź pierwszy schemat na Wikipedii lub stronie Martina Fowlera, aby uzyskać więcej informacji na temat MVC.

jeśli widok oczekuje danych od kontrolera, to są one skutecznie powiązane ze sobą jako para (kontroler, widok).

Podczas gdy widok ogólnie akceptuje dane, w większości platform MVC nie zależy on od określonych kontrolerów. Wyjątek stanowią na przykład rodzina JavaServer Faces. Ogólnie rzecz biorąc, frameworki, takie jak Rails, Django lub Spring MVC, pozwalają rozdzielić widoki od kontrolerów, przekazując dane (kontekst, zwykle mapę / słownik / torbę) do widoku (gdzie widok jest implementacją wzorca widoku szablonu ).

Czy odpowiedź zmienia się, gdy masz pojęcie silnie typowanego widoku (jak w ASP.NET MVC), czy nie?

To, czy Twój język programowania jest silnie napisany, nie ma wpływu na sposób organizowania aplikacji.

Pytanie, które zadajesz, jest od czasu do czasu omawiane w moim zespole. Kłócimy się o dwa podejścia, które mają swoje wady i zalety.

Pierwszy argumentuje, że kontroler może zaktualizować widok według następującego wzoru. Nasłuchuje zarówno GUI, jak i zdarzeń modelowych. Kiedy wystąpi zdarzenie GUI, wykonuje wymaganą akcję w modelu, która z kolei uruchamia się i zdarzenie. Teraz administrator zwykle aktualizuje widok wymaganymi danymi.

Drugie podejście polega na tym, że sam widok nasłuchuje zdarzeń modelowych i aktualizuje się o dane, które są dołączone do zdarzenia lub poprzez zapytanie do modelu.

W pierwszym podejściu masz więcej mocy do kontrolera, który naprawdę kontroluje wszystko, co dzieje się w twojej aplikacji. Moc decydowania, w jaki sposób widok powinien zostać zaktualizowany zgodnie z tym, jakie wydarzenie jest w jego rękach, i w ten sposób utrzymujesz swój widok w czystości. Jednak, jak powiedziałeś, w ten sposób masz połączony widok i kontroler.

W drugim momencie oddzielasz je, ale twój widok faktycznie kontroluje się w jakiś sposób.