Na pewno nie pierwszy raz ten temat się pojawia. Natomiast, na tyle tematów i artykułów jakie przejrzałem nadal jest ich za mało lub są pisane w zbyt mało zrozumiały dla mnie sposób. A chciałbym (w końcu) nauczyć się korzystać z MVC, bo osoby z którymi rozmawiam chwalą sobie to rozwiązanie. Mam do napisanie mała aplikację, która będzie miała dwa okienka i jakiś model danych, także wydaje mi się, że to idealny moment, żeby na tak niewielkim kodzie spróbować całość zaimplementować.
Jednak problem leży po stronie zrozumienia MVC, bo trochę on do mnie nie trafia. Mam wrażenie, że kod który muszę napisać (zgodnie ze wzorcem) jest niepotrzebnie podzielony i rozwleczony (po prostu nie widzę profitów ze stosowania MVC, ale pewnie dlatego że nigdy z niego nie korzystałem).
Do rzeczy, trafiłem na taki schemat tego wzorca (http://rdn-consulting.com/blog/wp-content/uploads/2008/01/mvc-pv.gif) i ten chyba do mnie trafia, ale mimo to chciałbym tutaj go opisać własnymi słowami i prosiłbym o parę słów komentarza, czy ja na pewno dobrze rozumiem.
Model, to raczej sprawa jasna, repozytorium danych, zestaw klas do obsługi tego repozytorium, itp. Generalnie część odpowiedzialna za przechowywanie danych.
View, to w większości przypadków będzie okienko z interfejsem użytkownika.
Controller, to to magiczne coś, nad czym się zastanawiam. Ono ma niby łączyć model i widokiem przez...eventy? Tylko i wyłącznie?
Przykładowo jak ja to widzę. Użytkownik klika przycisk w widoku. Przycisk (dla użytkownika) służy do zapisu danych z trzech Textbox'ów z formatki, np. do pliku. Tyle wie użytkownik.
A to co pod spodem się dzieje, to: po kliknięciu, leci event do kontrolera. Ten odbiera go i reaguje w ten sposób, że zbiera dane z formatki (ale w samym zdarzeniu chyba też takie dane można przekazać, a może trzeba?), a następnie wywołuje jakąś metodę modelu (tutaj już nie event), która fizycznie zapisuje dane, np. do pliku. W odpowiedzi model zwraca (znowu przez event???) odpowiedź o poprawności lub błędzie do kontrolera. Ten dopiero wywołuje metodę widoku lub bezpośrednio (to drugie chyba częściej) modyfikuje formatkę jeśli należy ją zmodyfikować, albo zamyka po prostu bieżącą formatkę, albo wypisuje błąd?
I to o to w tym chodzi?
Jak tak, to jakie to ma profity w stosunku do kodu z pominiętym kontrolerem? Znika sporo eventów, widok używałby bezpośrednio metod modelu i też działa. Więc czemu jest takie parcie na MVC (lub inne jemu podobne)?
Oddzielna sprawa: w którym momencie jest walidacja danych? Można chyba spróbować robić ją po każdym TextChanged w Textbox'ach. Ale, według powyższego schematu, dane byłyby wysyłane do konrolera przez event, a ten sprawdzałby je w jakiś tam sposób (np. mógłby mieć dodatkowy obiekt jakiejś klasy, która by to sprawdzała). Następnie odsyłałby to do widoku. Czy tego typu walidacja miałaby następować bezpośrednio w widoku?
Drugi moment (odnosząc się do mojego pierwszego przykładu), to gdzieś "na trasie" między naciśnięciem przycisku, przez zapis, a powrotem z informacją o powodzeniu operacji. I w tym wypadku, walidacja powinna być przed wysłaniem danych do modelu, w sensie w kontrolerze zaraz po odebraniu eventu od widoku i jeśli dane są poprawne wywołuję dopiero metodę modelu, czy dopiero w modelu powinny być sprawdzane dane, a kontroler czekałby na ewentualne wyjątki, żeby za chwile je przekazać użytkownikowi?
Proszę o jakieś uwagi albo dobre artykuły (nie pierwsze lepsze z Google, bo te nie bardzo do mnie przemawiają...). Wiem że sporo tego napisałem, ale chciałbym wreszcie to zrozumieć, tym bardziej że niedługo czeka mnie większa aplikacja do zrobienia, więc chciałbym i ją spróbować zrobić według konwencji MVC (o ile ją zrozumiem).