Cześć Wam!
Otwierając programistyczny “tydzień” na blogu, chciałbym skupić się na wzorcach projektowych, tak jak to miało miejsce w w poprzednim wpisie o charakterze informatycznym. W moich rozważaniach 08.11 zaznaczyłem, które wzorce według mnie są najważniejsze i zapowiedziałem, że na każdy z nich chciałbym poświęcić osobny wpis. Słowa zamieniam w czyny, więc dzisiaj weźmy pod lupę wzorzec MVC (Model – View – Controller). Chciałbym również z góry przeprosić za dość częste powtarzanie takich słów jak: Model, View (Widok), Kontroler; aby szczegółowo wyczerpać dany temat nagminne używanie tych słów wydaje mi się niezbędne. Do dzieła!
Co mówi wikipedia? Czyli trochę historii i suchej definicji
Model-View-Controller został zaprojektowany w 1979 roku przez norweskiego programistę Trygve Reenskaug pracującego wtedy nad językiem Smalltalk w laboratoriach Xerox i 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“.
Nie byłbym sobą, gdybym na początku nie przytoczył formalnej definicji z Wikipedii:
Model-View-Controller (pol. Model-Widok-Kontroler) – 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ę. MVC nie był traktowany jako samodzielny wzorzec również w pracy „Design Patterns: Elements of Reusable Object-Oriented Software“ autorstwa „Bandy Czworga”.
Słowa zachęty
Myślę, że mogę zaryzykować i stwierdzić, że Model – Widok – Kontroler to obecnie najprawdopodobniej najpopularniejszy wzorzec projektowy, co za tym idzie jest najczęściej wykorzystywany w praktyce. Myślę, że warto w stu procentach wykorzystywać tą praktykę programowania, ponieważ stosowanie MVC sprawia, że nasz kod jest:
- prosty do rozwijania czy ponownego użycia
- czysty
Wielu programistów (w tym też ja z moich początków) skupia się na tym, by nasze środowisko w którym kodujemy wyglądało super, by postępy w programowaniu szły niczym błyskawica – co czasami mija się z jakością naszego oprogramowania. Czasami warto zahamować i pomyśleć co można zrobić, by nasz kod był czytelniejszy i mógłby być rozwijany przez osoby trzecie nie znając zbytnio jego specyfikacji.
MVC
Założenie wzorca jest dosyć proste. MVC dba o to, by elementy / warstwy naszej aplikacji były odpowiednio od siebie oddzielone. W tym przypadku chodzi o: logikę, prezentację (widok) oraz dane. Przyjrzyjmy się bardziej szczegółowo:
- Model to warstwa która reprezentuje naszą logikę biznesową. W tej warstwie znajdują się obiekty, które służą do wykonywania operacji związanych z implementacją funkcjonalności naszej aplikacji
- Widok to warstwa prezentacji danych (czyli to, co widzi użytkownik). Odpowiedzialny jest za nic innego, jak prezentację wizualną użytkownikowi wyników, które są wynikiem działań logiki biznesowej (czyli Modelu)
- Kontroler to warstwa która obsługuje żądania użytkownika. Żądania przekierowywane są do odpowiednich metod w Modelu, które z kolei przekażą odpowiednie dane użytkownikowi – czyli Modelowi
Dla zobrazowania:
Model
Większość programistów specjalizujących się w aplikacjach typowo webowych (J2EE) ma problem z dobrym zrozumieniem pojęcia “Model” w wzorcu projektowym MVC. Bo przecież w większości aplikacji w pakietach “model” ładujemy jedynie encje, odwzorowujące naszą bazową encje. Nie twierdzę, że jest złe, ale niestety mylnie nakierowuje to nas na dobre spostrzeganie modelu w tym wzorcu. To, co najważniejsze: Model to logika biznesowa! Są to obiekty wykonujące wszelakiego rodzaju logikę biznesową związaną z funkcjonalnością naszej aplikacji. To nie tylko encja a cała logika biznesowa wraz z mapowaniem obiektowo – relacyjnym. Poprawnie napisany Model to taki, kiedy zdecydujemy np przenieść nasz interfejs na inną platformę (np z Androida na Webową) i jedynie co będziemy musieli zrobić, to pozmieniać nasze żądania w kontrolerach oraz warstwę widoku, zaś logika biznesowa pozostanie bez zmian.
Widok
Moim zdaniem najprostszy komponent tego wzorca. Widok służy jedynie do prezentacji danych dla użytkownika. Na tym można by zakończyć, ale moim zdaniem warto rozszerzyć nieco wątek. W podejściu MVC to właśnie Model informuje odpowiednie komponenty Widoku o zmianach w Modelu i potrzebie aktualizacji Widoku. Czyli w drugą stronę…odpowiednie części Widoku mogą wykorzystywać komponenty Modelu do pobierania danych potrzebnych do wygenerowania Widoku. Najczęstszym błędem popełnianym przez programistów jest modyfikowanie Modelu z poziomu Widoku. Trochę zagmatwałem, ale jeśli ktokolwiek ma problem ze zrozumieniem to polecam kartkę papieru i rozrysować sobie moje słowa.
Kontroler
Powyższa warstwa ma jedno proste zadanie: przekierowywanie wszystkich żądań użytkownika na odpowiednie wywołania w warstwie Modelu. Można sobie wyobrazić, że jest to tak jakby dźwig, który kontroluję przepływ danych między odpowiednimi warstwami. Najczęstszym błędem, który popełniają programiści w tej warstwie to wykonywanie logiki biznesowej wewnątrz kontrolera. Ten błąd prowadzi do tego, że mamy model ściśle powiązany z kontrolerem. W związku z czym (jak już pisałem w przypadku Modelu), nie będzie możliwe przenieść naszą logikę biznesową na inną warstwę reprezentacyjną, np. całkowita zmiana szaty graficznej.
Zalety MVC
- ułatwia odnalezienie konkretnej części kodu
- oddzielenie logiki biznesowej od widoku
- podział na moduły porządkujące kod aplikacji
- brak zależności modelu od widoku
- łatwiejsza rozbudowa poprzez modułową budowę
- zapobiega tworzeniu się bałaganu w kodzie (clean-code)
- ułatwia prace zespołową
Reasumując, na pewno warto stosować ten wzorzec. Nie ma sensu generować niepotrzebnego “burdelu” w naszym kodzie, kiedy wszystko może być ładne, przejrzyste i łatwe do “refaktoringu” czy przeniesienia serwera na inny widok. Mam nadzieje, że wszystkie wątpliwości dotyczące tego wzorca zostały rozwiane, a niektórzy mogli też np. poznać coś nowego. W następnym wpisie programistycznym (czyli za dwa tygodnie) chciałbym szczegółowiej przyjrzeć się wzorcu o nazwie Singleton.
Pozdrawiam serdecznie,
biegajacyprogramista.pl
