Model

Model ma za zadanie enkapsulacji danych od reszty aplikacji, ponieważ jest on warstwą logiczna/biznesowa. Specyfika MVC ma czynić model nie zależnym od warstwy widoku i kontrolera, ponieważ te dwie warstwy odpowiadają razem za składanie interfejsu użytkownika. Obiekt może spełniać role modelu dla bardziej skomplikowanych połączeń niż te które wchodzą w skład MVC.

Zobacz zakres obowiązków Modelu(Domain Model) i przekazywanie danych(Transaction Script) aby zorganizować poprawie swoja warstwę logiczna.

Bierny Model

W trybie biernym(pasywnym), obiekty używane w modelu, nie zostały zaprojektowane do używania ich w trójce MVC. Kontroler jest odpowiedzialny za sygnalizacje widokowi, gdy wykonuje on operacje na modelu, które wymagają zaktualizowania danych w widoku.

Bierny model jest powszechnie wykorzystywany w WEB MVC. Surowe żądanie/odpowiedz z cyklu HTTP nie wymaga aktywnego modelu. Interfejs użytkownika zostaje za każdym zbudowany na nowo, po mino zmian tylko w obrębie modelu (**autor: w aplikacji PHP nie mamy "trwałej" sesji i za każdym odwołaniem cały interfejs użytkownika, jest budowany na nowo - w przeciwieństwie do aplikacji, np.: systemowych, gdzie to zainicjowany szkielet jest wykorzystywany ciągle**). Doskonale to widać w PHP gdzie żaden stan nie jest zachowywany pomiędzy żądaniami klienta (budowa od nowa całego interfejsu).

Aktywny Model

W aktywnym Modelu, klasy modelu posiadają mechanizm zawiadomień, zwykle stosuje się w tym celu wzorzec Obserwator. Dzięki takiemu rozwiązaniu, niepowiązany widok jak i komponenty kontrolera zostają poinformowane o zmianach zachodzących w modelu. Ponieważ te komponenty rejestrują siebie w modelu, a model nie ma pojęcia o specyfikacji widoku i kontrolera, to nie niszczy niezależności modelu.

Mechanizm zawiadomień dostarcza natychmiastowego uaktualnienia informacji, czyli cechy charakterystycznej dla aplikacji MVC z GUI (Graphical User Interfaces, graficzny interfejs użytkownika).

Model Adaptator

Jest możliwe wykorzystanie wzorca Adapter (Adaptator) aby wprowadzić możliwość rozmnożenia klas modelu lub aby wdrożyć inna cechę modelu aktywnego do modelu biernego, w celu uzyskania zamiany model biernego w aktywny.

Model prezentacyjny

Założenie MVC ma na celu odseparować interfejs użytkownika od warstwy logicznej. Czyniąc tak, zyskujemy możliwość wzbogacenia naszej biblioteki komponentów, mogących być wtórnie wdrażanych w naszych aplikacjach MVC. Czasami, dane albo relacja(**Przykładowo DataGrid**) która przynależy do interfejsu użytkownika(prezentuje jakieś dane), może być zawarte po stronie modelu. Stąd obiekty które wydawałyby się być z góry modelem tak naprawdę są częścią interfejsu, to znaczy widoku i kontrolera.

Na przykład: scrollbar, pozycje i sortowanie kolumn(**tłumacz: wspomniany DataGrid).

Wyżej wspomniane sytuacje, są czasem nazywane Application Model (Model aplikacji) i określa się je wzorcem MMVC, ponieważ występują dwa oddzielne modele.