MVC w aplikacjach internetowych

Model View Controller
Po dłuższej nieobecności wracamy z jednym ze wzorców projektowych na „tapecie”. Ten wpis poświęcę „MVC”, czyli Model – View – Controller.
Większość współczesnych aplikacji działa właśnie w tym rozwiązaniu. Internauta nie zobaczy różnicy, bo wszystko dzieje się niejako ‚pod spodem’. Postaram się dobrze opisać każdą część tego „koderskiego” trójkąta.

Historia

Pattern został zaprojektowany w 1979 roku przez norweskiego programistę, Trygve Reenskaug. Pracował on wtedy nad językiem Smalltalk w laboratoriach Xerox. Początkowo nosił nazwę Model-View-Editor. Oryginalna implementacja została szczegółowo opisana we wpływowej pracy „Applications Programming in Smalltalk-80: How to use Model–View–Controller“

Trzech Muszkieterów w Twojej aplikacji webowej

Zaletą, którą Programiści powtarzają jak mantrę jest to, że dzięki MVC można osiągnąć taki efekt. 3 warstwy, a każda z nich jest odpowiada za co innego.

  • Model – Model danych – opis struktur danych i powiązań pomiędzy nimi

  • View –  Interfejs, czyli to, co widzi użytkownik

  • Controller – Logika działania – powiązania między zdarzeniami zachodzącymi w systemie.

Takie rozwiązanie niesie ze sobą spore plusy. Pisząc aplikację dla samego siebie, nie musi Ci zależeć na porządku, szczególnie jeżeli jest to mała aplikacja. Jeżeli jakaś firma zleci Ci do wykonania projekt, używanie wzorca projektowego jest niezbędne! Być może stworzysz aplikację, która po kilku latach zostanie oddana do renowacji innej firmie. Będąc twórcą projektu musisz zadbać, aby inne osoby zajmujące się Twoim projektem w przyszłości, umiały się w nim połapać.

Jeśli jesteś programistą to wiesz, że nie ma nic gorszego od poprawiania/modyfikacji czyjegoś kodu.

Widząc takie rozwiązanie mogę stanowczo stwierdzić, że mamy tutaj pewnego rodzaju porządek, strukturę. To, o czym należy pamiętać to to, że: Model = Logika Biznesowa. Niezrozumienie tego jest bardzo częstym błędem w  wielu projektach.

W jednym z ostatnich wpisów przygotowałem zestawienie najpopularniejszych frameworków. Post znajdziesz tutaj. Dziś po części opowiadam o tym, jak dany framework jest zbudowany. Mimo, że jest ich bardzo wiele, działają na podobnej zasadzie, stosując wzorce architektoniczne.

Jak już pisałem wcześniej, najważniejszą korzyścią jest całkowita separacja danych (i reguł nimi rządzących) od sposobu ich prezentacji. Aby to było możliwe, obiekty warstwy modelu nie mogą być świadome sposobu, w jaki zostaną zaprezentowane. To widok, wiedząc z jakimi obiektami ma do czynienia, może je pokazać. „Dyryguje” tym Controller. Jego ogólne zadania polegają na analizowaniu zapytania użytkownika i na podstawie tej analizy:

  • pobraniu odpowiednich obiektów modelu
  • wybraniu odpowiedniego widoku i przekazaniu do niego wcześniej wybranych obiektów.

Żeby nie było tak słodko…

Można dodać też, a może i przede wszystkim, że Controller zajmuje się delegacją żądań HTTP. Przypisanie zadania przygotowania danych dla widoku to słaby punkt tego wzorca. Po pierwsze, kontroler musi wiedzieć jakie dane przygotować, a zatem które metody modelu wywołać, co de facto jest częścią logiki biznesowej. Po drugie prowadzi to do pisania w wielu kontrolerach tego samego kodu.

Kiedy stosować MVC?

Najpopularniejszą odpowiedzią na wyżej postawione pytanie jest:

  • aplikacja jest duża i skomplikowana
  • aplikacja musi być elastyczna, mieć możliwość rozbudowy
  • pracuje nad nią wielu ludzi (możemy w łatwy sposób podzielić odpowiedzialność za poszczególne elementy systemu)
Stosujecie MVC w swoich projektach? Z jakimi problemami spotykaliście się najczęściej? Jakie projekty zaprogramowaliście, bądź programujecie w tym wzorcu? Dajcie znać w komentarzu!
Rafał Fidurski