Trudno byłoby zbudować dom bez projektu architektonicznego, który opisywałby materiały, elektrykę, rozkład pomieszczeń czy chociażby wziął pod uwagę właściwości geologiczne terenu, na którym stawia się budynek. Każdy z tych aspektów jest niezmiernie ważny, ponieważ nie uwzględniony może doprowadzić do poważnej katastrofy. Aplikacje, które tworzymy, podobnie jak budynki, mogą rozlecieć się, jeśli nie zostaną dobrze zaplanowane. Dodawanie kolejnych elementów bez planu i pomysłu spowoduje chaos i niekontrolowany rozrost kodu, a z czasem zablokuje dalszy rozwój naszego projektu.

Architektura na szczęście to obszar, który w IT również został zagospodarowany. Do dyspozycji mamy wiele różnych podejść, każde będzie dobre dla innych zastosowań. Dzisiaj postaram omówić się jeden z najpopularniejszych wzorców architektonicznych, który miał ogromny wpływ na to jak rozwijały się aplikacje internetowe na przestrzeni lat. Powitajmy MVC.

W laboratorium

Koncern Xerox pojawiał się już wielokrotnie w moich opowieściach. Nie inaczej jest również i w tym przypadku. Pod koniec lat 70. XX wieku programista norweskiego pochodzenia Trygve Reenskaug pracował w Xerox nad zorientowanym obiektowo językiem Smalltalk. W ramach swoich prac opracował koncepcję wzorca MVC. MVC miał pomóc w rozwiązaniu problemu użytkowników, którzy kontrolują duże i złożone zbiory danych. Pierwotnie zaproponowane podejście Trygve nazwał Model-View-Editor, jednak z czasem przekształcił nazwę na Model-View-Controller, która została z nami do dziś.

Główne założenie MVC to podzielenie całej aplikacji na trzy niezależne warstwy, które uporządkują architekturę systemu. Każda warstwa stanowi logiczną całość. Zmiany w którejkolwiek warstwie nie powinny wymuszać ogromnych zmian w pozostałych warstwach. Pojawia się pytanie - jakie to warstwy? Zgodnie z nazwą: Model (model danych), View (widok, interfejs, czyli to, co widzi użytkownik) oraz Controller (logika).

Aktualnie MVC jest jednym z najpopularnieszych podejść architektonicznych, które wykorzystujemy w web-developmencie. Frameworki frontendowe, które wykorzystują MVC to: Ember, Angular.js, Backbone. Wymienione przeze mnie rozwiązania nie są już tak popularne jak kiedyś. Obecnie na frontendzie częściej stosowana będzie architektura komponentowa lub MVVM. Dlaczego tak się stało? O tym w dalszej części opowieści.

Na backendzie MVC ma się nadal całkiem nieźle, znajdziemy ją między innymi w ASP.NET, Django, Laravel'u i wielu innych. Spróbujmy omówić poszczególne warstwy i ich zadanie w aplikacji.

Model

Model to reprezentacja danych w naszej aplikacji. Główne zadanie modelu to określenie z jakich składników zbudowany jest dany obiekt oraz komunikacja z bazą danych (operacje zapisu, modyfikacji, odczytu i usuwania danych z bazy danych). Przykładowo, jeśli budujemy aplikację sprzedającą warzywa to model będzie określał takie jej elementy jak klient, warzywo, zamówienie. Każdy z tych elementów będzie zawierał informacje o właściwościach, które będą niezbędne z perspektywy logiki biznesowej. Na tym kończy się rola modelu.

Model sam w sobie nie może komunikować się z widokiem bezpośrednio. Pośrednikiem pomiędzy tymi dwoma warstwami jest warstwa kontrolera (Controller). Wyróżniamy dwa typy modelu: model pasywny i model aktywny. Model pasywny to taki, który nigdy nie zmienia swojego stanu bez udziału kontrolera. W model aktywnym natomiast stan może ulec samoczynnej zmianie, wówczas taki model powinien mieć zaimplementowaną funkcjonalność powiadamiania odpowiedniego kontrolera o zmianie, która wystąpiła.

Controller

Funkcja pośrednika powoduje, że to właśnie kontroler jest odpowiedzialny za odpowiedni przepływ danych w aplikacji. To właśnie on obsługuje zapytania użytkownika. Zatem jeśli użytkownik aplikacji wypełnił formularz, który został wysłany np. za pomocą metody HTTP POST, to właśnie kontroler odbierze to żądanie i będzie je dalej przetwarzał. Podejmie decyzję, co z nim zrobić w następnym kroku: zmodyfikować widok, zmienić stan modelu czy może przekazać sterowanie do innego kontrolera.

Ponadto kontroler odpowiada za obsługę logiki biznesowej. Można śmiało powiedzieć, że kontroler jest mózgiem całej aplikacji.

View

MVC powstało przede wszystkim do obsługi aplikacji wykorzystujących GUI (Graficzny Interfejs Użytkownika). View, czyli widok - odpowiada za obsługę pracy użytkownika - wyświetlenie danych, obsługę zdarzeń i przekazanie ich do kontrolera. Innymi słowy to warstwa, dzięki której wszystko wygląda ładnie i działa (przynajmniej z perspektywy użytkownika powinno).

Ot i cała filozofia MVC. Główne założenie to izolacja poszczególnych warstw aplikacji i wykorzystanie warstwy pośredniczącej, aby zarządzać przepływem informacji. Minimalizuje to zależności pomiędzy poszczególnymi elementami systemu a same widoki mogę być dynamicznie rozwijane bez większego udziału logiki i modelu, co ostatecznie wpływa na niższy koszt rozbudowy projektu.

O dobrych i złych stronach MVC

O wielu dobrych stronach już napisałem powyżej, zatem podsumowując, MVC:

• stawia na prostotę, podział na trzy warstwy jest bardzo jasny i klarowny,

• pozwala na łatwe rozwijanie widoków, wynika to z tego, że warstwa logiki, nie zmienia się tak często jak warstwa prezentacyjna - a w związku z ich rozdziałem, możemy rozwijać je niezależnie,

• nie uzależnia modelu od widoku - model zawsze jest niezależny, a różne widoki mogą wykorzystywać jeden model i prezentować dane w dowolny sposób.

Nic nie jest jednak czarno-białe. Jeśli są dobre strony, to i złe muszą być. Wynikają one przede wszystkim z powyższych zalet. Skoro model jest niezależny od widoku i może być zaimplementowany wielokrotnie niskim kosztem, to zmiana modelu będzie już trudniejsza. Każda zmiana modelu będzie wymagała znalezienia wszystkich widoków z niego korzystających i ich dostosowania.

Wydzielenie logiki do osobnej warstwy i jednoczesne utrzymanie części logiki na widoku (tej powiązanej z komunikacją) powoduje wzrost złożoności i utrudnia testowanie (w szczególności testowanie widoku).

3 + 2 = 1

Często zdarza się, że MVC można również rozpatrywać jako wzorzec złożony, czyli taki który powstał z wymieszania kilku innych wzorców projektowych. Najpopularniejszym podzialem jest wskazanie 3 wzorców: kompozyt, strategia i obserwator. Gang Czworga dokłada do tego zestawu jeszcze 2 wzorce: factory method (metoda wytwórcza) oraz dekorator.

Nie będę tutaj opisywał co robi każdy z powyższych wzorców. Ważne jest natomiast to, że znajdziemy je stosując MVC w każdej z trzech warstw.

Gdyby ktoś nie wiedział kim jest Gang Czworga to dopowiadam. Jest to czterech autorów: Erich Gamma, Richard Helm, Ralph Johnson i John Vlissides, którzy w 1994 roku napisali książkę o wzorcach projektowych, która jest uznawana w środowisku IT za jedną z lepszych dotykających tej tematyki. Do dziś jest to bestseller Amazona.

Facebook i MVC

Przed 2014 rokiem Facebook był zbudowany w oparciu o architekturę MVC. Jednak postanowiono z niej zrezygnować wraz z rozrostem ich aplikacji. Wynikało to przede wszystkim z faktu, że pomiędzy widokami a kontrolerami powstawało wiele dwukierunkowych powiązań, w związku z wykorzystaniem two-way data binding, o którym pisałem tutaj. Takie podejście powodowało, że MVC w przypadku Facebooka, nie było rozwiązaniem skalowalnym. Dwukierunkowy przepływ danych obejmuje relacje many-to-many, które są trudne do śledzenia i utrzymania.

Było to szczególnie widoczne, kiedy Facebook wprowadził czat do swojej aplikacji. Czat wyświetlał informację o nieprzeczytanych wiadomościach, nawet wtedy gdy zostały one przeczytane wcześniej (lub nawet oznaczone jako przeczytane). Przez dłuższy czas deweloperzy Facebook’a walczyli z tym bugiem, ale nie byli w stanie go naprawić. Ostatecznie rozwiązano problem, rezygnując z architektury MVC na rzecz architektury jednokierunkowej Flux.

Przypadek Facebooka pokazuje, że dobór architektury i jej umiejętne wykorzystanie w ramach aplikacji może być trudny. Czasami z raz podjętych decyzji musimy się wycofać, nawet jeśli jest to zmiana ogromna.

Czy to koniec MVC?

MVC było wykorzystywane przez wiele lat również na frontendzie. Środowisko frontendowe postawiło jednak odejść od MVC na rzecz MVVM lub po prostu architektury komponentowej z dodatkiem Fluxa lub Reduxa. MVC jest często krytykowane za zbyt dużą zależność widoku od modelu, co powoduje, że zmiany w modelu zawsze powodują zmiany w widoku.

Dodatkowo w aplikacjach frontendowych, które renderowane są po stronie klienta, kontrolery są jeszcze bardziej uzależnione od widoku, czego doświadczył Facebook w 2014 roku. Modele są ponadto przeładowane, ponieważ przechowują informacje o stanie interfejsu użytkownika (produkty, artykuły, wspomniane wcześniej warzywa) oraz o stanie samej aplikacji (ustawienia widoku, kolor theme’u, wybrany język). Przy tak określonych zadaniach złamana zostanie zasada Single Responsibility (jedna z pięciu zasad SOLID). Model zajmuje się zarządzaniem różnymi rodzajami stanu i brakuje mu oddzielnych mechanizmów od ich obsługi, a kontroler ogarnia zdarzenia przychodzące z widoku i logikę biznesową.

Obecnie MVC jest nadal jednym z najpopularniejszych standardów do budowania skalowalnych projektów webowych. Świat frontendu go wypiera, modyfikuje na swoje potrzeby (jak chociażby MVVM), ale nie zmienia to faktu, że wśród programistów to nadal jeden z najprostszych schematów projektowania do zaimplementowania w aplikacjach i warto go znać.

Podsumowanie

MVC to jedna najstarszych dostępnych architektur. Warto się z nią zaznajomić, w szczególności dlatego, że jest szeroko rozpowszechniona w świecie web-developmentu. Jeśli rozłożymy ją na części to okaże się, że pod spodem znajdziemy wiele ciekawych wzorców projektowych.

Współczesne rozwiązania architektoniczne częściej powiązane są z bardziej zaawansowanymi schematami niż MVC, często nawiązującymi do nowszych rozwiązań opartych na specjalistycznych technologiach czy opartych o domenę. Pomimo to MVC jest solidną architekturą, która dobrze użyta w wielu przypadkach sprawdzi się bardzo dobrze i pozwoli nam lepiej zrozumieć te bardziej nowoczesne podejścia.