Prolog

Trzy lata temu spotkałem się po raz pierwszy ze skrótem MVC, zaciekawiła mnie ta architektura i pomysł na aplikacje. Jestem .netowcem więc sięgnąłem po ASP MVC. Przejście nie było łatwe do tamtej pory programowałem jedynie w Winforms i WebForms to drugie zmienia człowieka i pozostawia wielką bliznę na psychice.

Bestiariusz

O MVC wiedziałem tylko tyle, że jest to wzorzec architektoniczny, który w dużym skrócie rozdziela aplikacje na trzy nie zależne części Model, Widok i kontroler. W modelu trzymamy strukturę danych, która za pomocą akcji kontrolera zostaje wyświetlona w widoku (w dużym uproszczeniu).

Poniższy opis  na podstawie Wikipedii.

Model

Warstwa najbardziej niezależna, która powinna skupiać w sobie logikę oraz dostęp do danych.

Kontroler (Controler)

Warstwa która pośredniczy między modelem a widokiem ale nie zawsze. Pobiera dane z widoku przekazuje do modelu.

Widok (View)

Prezentacja danych w graficznym interfejsie użytkownika. Widok posiada bezpośrednie referencje do modeli gdy kontroler zażąda odświeżenia danych.

Rozdział pierwszy – zderzenie z rzeczywistością

Po krótce przedstawiony MVC na tamtą chwile wystarczył, sięgnąłem po tutorial z jutuba, a na zakończenie rozpocząłem pracę nad projektem, który…. się nie udał. Wyznaje zasadę, że pierwsze projekty w nowym środowisku nigdy nie wychodzą tak jak chce. Sprawdza się.

Rozdział drugi – pogłębienie się depresji

Kolejny projekt był znacznie lepszy ale  zawsze jest jakieś ale. Rozpoczołem go standardowo baza, Entity Framework do modelu, mapowanie z bazy (Base First), kontrolery „spinam” z modelem bezpośrednio (bez interfejsów) i wrzucam na widok. Zrobiłem ładny projekt, znaczy działał i tylko tyle. Bo został ubity po wylądowaniu na teście, nie z mojej winy. Zleceniodawca się rozmyślił. Potem jeszcze powrócił na chwilę z nadzieją, by w końcu skończyć swoje istnienie w odmętach naszej wewnętrznej sieci.

Ale nie o tym będzie mowa. Projekt przyczynił się do bardziej ambitnego podejścia do MVC. Dalej nie zgłębiałem tego wzorca jak należy ale uznałem, że warto zapoznać się ze wzorcem repozytorium, będącym warstwą pomiędzy baza a aplikacją. Moje repozytorium było w osobnym projekcie, osobny projekt był MVC .net (kontrolery i widoki). Do repozytorium można było dostać się za pomocą interfejsów. Za czołem długą drogę w poznawaniu SOLID (i innych nie zrozumiałych słów) i jego stosowaniu.

Uświadomiłem sobie, że kontrolery nie służą do generowania logiki, są tylko przejściem pomiędzy stanami. Zdałem sobie sprawę z tego trochę późno, gdy z refaktoryzacją nie było tak łatwo.

Nie wszystko udało się uleczyć. Poznałem kilka wzorców projektowych ale wtedy unit testów nie ruszyłem, nie znałem Event Stromingu, który pomógł by mi zrozumieć procesy zachodzące w systemie.

Kolejny projekt – krok naprzód dwa kroki w bok

Walczyłem z kodem, walka nierówna była i skazana na porażkę ale to co zostało napisane  posłużyło za podstawy do stworzenia kolejnej wersji maratonu (Aplikacji do obsługi maratonu rowerowego), która okazała się znacznie lepsza od pozostałych pięciu wersji. Posłużyła za przykład jak ważna jest architektura i jej odpowiednie dobranie do problemu, a co najważniejsze, jak ważne jest zrozumienie i właściwe przedstawienie procesów.

Problem z ostatnią wersją Maratonu polegał na tym, że usilnie chciałem dzielić aplikacje na moduły, chciałem tworzyć niezależne warstwy interfejsów i modeli, które można poddać wymianie, chciałem zrobić wymienny interfejs użytkownika, robiłem to tak naprawdę po omacku bez właściwego projektu. Aplikacja zadziałała, ja zakończyłem przygodę z tym system, na tej właśnie wersji zdając sobie sprawę z braku możliwości jej rozwijania.

Co stało u podstaw błędnych decyzji?

Powodem błędnego zrozumienia MVC było ślepe podążanie za tutorialem na początku mojej przygody z tym wzorcem, nie skupiłem się na zrozumieniu tylko na rozwiązaniu problemu.  Stąd też moje wątpliwości co do implementacji tego wzorca.

Tutorial nie był źle zrobiony, po prostu pokazywał jak użyć ASP MVC, czyli do katalogu modelu wrzucić model który za pomocą kontrolerów chcemy zaprezentować na widoku. Ot i cała filozofia. Problem pojawił się dopiero gdy kontrolery oprócz przekazywania danych otrzymały wpływ na logikę czyli po prostu ją kreowały. Model jak to w przypadku ORM-a okazał się kupą klas z get-ami i set-ami, a widoki były ubogacane niepotrzebnymi danymi. Robiłem to w dobrej wierze, że tak trzeba bo problem, który przestawiałem (rozwiązywałem) był źle zaprojektowany już na starcie. Największym błędem było przyjęcie założenia, że rozwiązuje zadanie za pomocą MVC z .Net-a, bez właściwego rozeznania problemu z jakim się mierzyłem. Wybór narzędzia, architektury powinien nastąpić po procesie analizy dziedziny problemu.

W kolejnych projektach właśnie to wzbudziło moją wątpliwość w stosunku do MVC .Net-a, nie właściwe jego wykorzystanie.

Logika nie do modelu

Tą tezę będę potwierdzał (bądź obalał) w części drugiej, w oparciu o moją aplikację do obsługi maratonu rowerowego oraz torfowisko. Maraton powstał w oparciu o ASP MVC, Torfowisko nie potrzebuje już MVC.