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

Kontroler otrzymuje i interpretuje żądanie i przekazuje je do odpowiedniego modelu albo widoku. Kontroler jest odpowiedzialny zazwyczaj za wzywanie(włączanie) metod z modelu, w celu zmienienia jego stanu. W aktywnym modelu, zmiany te odbijaną się w widoku przez zmianę mechanizmu obsługi. W modelu biernym (pasywnym) kontroler jest odpowiedzialny za obwieszczenie widokowi kiedy ma zostać zaktualizowany, czyli pobrać dane z modelu.

W MVC kontroler nie jest mediatorem pomiędzy widokiem i modelem. Innymi słowy kontroler nie znajduje się pomiędzy widokiem i modelem. Zarówno kontroler jak i widok maja jednakowy dostęp do modelu. Kontroler nie kopiuje danych z modelu do widoku, pomimo że mógłby pobierać dane od modelu i oznajmiać widokowi iż zaszły
zmiany w modelu. Zobacz Presentation Abstraction Control tam warstwa kontrolera spełnia role mediatora pomiędzy prezentacja, a abstrakcja.

Słowo kontroler jest przeciążane(**ale to zabrzmiało obiektowo :-) **) przez różne rozumienie go w innych wzorcach. Zobacz what is a Controller Anyway (**czym jest więc kontroler**) przedstawionych jest tam parę wzorców z kontrolerem: Front Controller pełni rolę jedynego miejsca analizy danych napływających z HTTP. Page Controller kontroluje przepływ logiki dla danej pojedynczej strony. Application Controller kontroluje całą jedną aplikacje.

Ponieważ popularny MCV framework Struts implementuje kombinacje Front Controller i Application Controller, nie którzy ludzie przypuszczają, że to jest to pod czym rozumie się pojęcie kontrolera we wzorcu MVC dla aplikacjach internetowych. Z tego samego powodu wiele opisów wzorca Front Controller dla sieci WEB nie nakreśla wyraźnie różnic pomiędzy Front Controller i Application Controller.

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

Kontroler polega na modelu. Zmiana w modelu może wymagać równocześnie zmiany w kontrolerze.

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