W tradycyjnym smalltalkowskim MVC, widok i kontroler są ze sobą silnie powiązane. Każda instancja widoku jest połączona z pojedyncza instancja kontrolera i vice versa. Kontroler jest zaprojektowany tak, aby widok używał go jako wejścia. Widok także jest odpowiedzialny za tworzenie nowych widoków i kontrolerów.

Logiczne jest to ze pomiędzy widokiem, a kontrolerem są silne powiązania, ponieważ zajmują się wejściem i wyjściem, a w aplikacji są one silnie powiązane. W większości Framework’ów GUI (graficzny interfejs użytkownika) MVC widok i kontroler są prosto powiązane w jeden obiekt. Nazywany jest on wtedy Document View. Gdy kontroler i widok są złączone razem w jeden widok. Model zostaje nazwany wtedy dokumentem. Bierny model przerzuca więcej odpowiedzialności na kontroler, ponieważ to on musi powiadomić widok o tym że powinien zostać uaktualniony.

Współczesna sieć wprowadza więcej zmian we wzorcu MVC. Mianowicie przerzuca ona część obowiązków widoku na kontroler. Kontroler staje się odpowiedzialny za stworzenie i wybranie widoku, widok traci ten obowiązek na rzecz kontrolera.

Czasami obowiązek wybrania i stworzenia instancji odpowiedniego widoku, jest zlecany specjalnemu obiektowi. Znany jest on jako wzorzec Application Controller dla sieciowego MVC i View Handler dla GUI MVC.

Sztywności prośby/odpowiedzi cyklu HTTP czyni bardziej popularnym wariant z wykorzystaniem Document View, w WEB MVC, chociaż w aplikacjach typu GUI kontroler jest nadal mocno powiązany z widokiem. Żądanie HTTP jest analizowane przez kontroler, przetwarzane przez model, a odpowiedzialnym za prezentacje odpowiedz jest widok.

Tekst przełożony z angielskiego, oryginał znajduje się na:
http://www.phpwact.org/pattern/model_view_controller