Model-View-Controller

**Model-View-Controller** – wzorzec architektoniczny służący do organizowania struktury aplikacji posiadających graficzne interfejsy użytkownika. Wiele prac traktuje go jako pojedynczy wzorzec, lecz może on być także traktowany jako złożony wzorzec wykorzystujący idee wzorców prostych, takich jak Obserwator, Strategia czy Kompozyt. Oba te podejścia nie wykluczają się.

## Opis

**Model** jest aktywną reprezentacją pewnego fragmentu komputerowej reprezentacji problemu. W danej aplikacji może istnieć kilka modeli tego samego elementu. Model jest samodzielny — do poprawnej pracy nie wymaga obecności dwóch pozostałych części, dlatego komunikacja z nimi musi zachodzić w sposób niejawny[4]. Wyróżniane są dwa podstawowe rodzaje modeli:

* pasywny model,
* aktywny model.

We współczesnych aplikacjach modele mają postać klas udostępniających pewien interfejs programistyczny do manipulacji strukturami danych oraz wykonywania pewnych akcji.

**Widok** jest odpowiedzialny za prezentację danych w obrębie graficznego interfejsu użytkownika. Może składać się z podwidoków zarządzających mniejszymi elementami składowymi. Widoki posiadają bezpośrednie referencje do modeli, z których pobierają dane, gdy otrzymują od kontrolera żądanie odświeżenia. Widoki mogą także modyfikować stan modelu, jeśli dana modyfikacja dotyczy sposobu prezentacji danych.

Zadaniem **kontrolera** jest odbiór, przetworzenie oraz analiza danych wejściowych od użytkownika. W typowej aplikacji źródłami danych wejściowych będą klawiatura i mysz. Po przetworzeniu odebranych danych kontroler może wykonać następujące czynności:

* zmienić stan modelu,
* odświeżyć widok,
* przełączyć sterowanie na inny kontroler.

Każdy kontroler posiada bezpośrednie wskazania na określone modele i widoki, z którymi współpracuje, a jednocześnie w aplikacji może istnieć wiele kontrolerów. W danym momencie tylko jeden z nich steruje aplikacją.

## Wady i zalety

**Zalety:**

* Brak zależności modelu od widoków — model jest niezależny od widoków, dlatego w aplikacji może współistnieć wiele widoków prezentujących te same dane na różne sposoby.
* Łatwiejsza rozbudowa widoków — interfejs użytkownika oraz warstwa prezentacji zmieniają się o wiele częściej niż logika biznesowa aplikacji. Ponieważ obie te części są oddzielone, można łatwo dodawać oraz modyfikować istniejące widoki bez wpływu na kluczową część systemu.

**Wady:**

* Złożoność — implementacje MVC wprowadzają dodatkową warstwę abstrakcji oraz dodatkowe sposoby interakcji, czyniąc w ten sposób aplikację potencjalnie trudniejszą do debugowania.
* Kosztowne zmiany modelu — ponieważ model nie jest zależny od widoku, programiści rozwijający tę część nie muszą przejmować się zależnościami w przeciwnym kierunku. Jeżeli interfejs modelu ulega częstym zmianom, oznacza to konieczność poprawiania wszystkich korzystających z niego widoków.
* Trudne testowanie widoków — widoki są zależne od modeli, a ponadto zawierają własną, dodatkową logikę. Testowanie złożonych interfejsów użytkownika uważane jest za zadanie trudne.

## Zastosowania

Idee wzorca ***MVC*** zdobyły szerokie uznanie wśród programistów, aczkolwiek w obecnych czasach dużo częściej implementowane są późniejsze odmiany zamiast oryginalnej definicji.  Model-View-Controller jest stosowany w bibliotekach GUI, np. Java Swing, zaś implementacje w środowisku WWW dla tego języka wykorzystują Model-2 (Spring Framework). Framework Ruby on Rails przyczynił się do popularyzacji wśród aplikacji WWW pasywnego widoku, dalej określanego jednak przez autorów mianem MVC mimo znaczących różnic w budowie.  Na różnice w terminologii zwracają uwagę twórcy innego frameworka, Django.

## Zobacz także

* Obserwator
* Iterator
* Singleton
* Budowniczy
* Dekorator

## Referencje

1. ↑ Model-View-Controller (ang.). MSDN Library. [dostęp 2010-10-14].
2. ↑ Martin Fowler: GUI architectures (ang.). martinfowler.com. [dostęp 2010-10-15].
3. ↑ Opis architektury w dokumentacji Ruby On Rails: Getting started: The MVC architecture – por. z innymi źródłami.
4. ↑ Django FAQ: Django appears to be a MVC framework but you call the controller the "view" and the view the "template". How come you don't use the standard names? (ang.). [dostęp 2010-10-18.]