Stworzenie aplikacji, w której da się jawnie rozdzielić warstwy: logiki, prezentacji oraz danych, nie jest zadaniem trywialnym. W przeszłości wielu mądrych ludzi rwało sobie włosy z głowy, rozpatrując to zagadnienie.
Jak oddzielić logikę biznesową od warstwy prezentacji, w sytuacji gdy użytkowana przez nas technologia operuje na event handlerach/callbackach przypisanych do określonych zdarzeń wybranych przez nas kontrolek? Gdzie w tym wszystkim powinien znaleźć się model danych? Co by się stało, gdybyśmy chcieli wydzielić powtarzalny fragment logiki biznesowej?
Podobnych pytań jest sporo, ale odpowiedź można znaleźć, oczywiście przeglądając katalogi wzorców projektowych i dobrych praktyk. Nasza uwaga powinna skupić się na tzw. wzorcach architektonicznych, do których to zaliczany jest tytułowy MVC (model-view-controller), a także jego kolega MVVM (model-view-viewmodel). Dziś zajmę się tym pierwszym, natomiast do drugiego mam zamiar wrócić w kolejnym wpisie na blogu.
Idea wzorca MVC
Wzorzec MVC dba o to, by elementy naszej aplikacji (czy też strony internetowej) były odpowiednio odseparowane od siebie. Literka V, reprezentująca widok, jawnie sugeruje, że tego rodzaju wzorzec jest skierowany stricte do wdrożeń wykorzystujących GUI jako integralny element tworzonego rozwiązania.
Dzięki podzieleniu aplikacji na trzy warstwy znacznie zwiększamy reużywalność kodu. Za pomocą MVC możemy np. kilkukrotnie użyć tego samego modelu danych czy też powtórzyć akcje kontrolera. Największy problem stanowi oczywiście widok, który w większości technologii jest tworzony częściowo statycznie. Poniżej skrócona charakterystyka poszczególnych elementów tego wzorca projektowego.
Controller
Kontroler to w pewnym sensie miejsce, od którego wszystko się zaczyna we wzorcu MVC (mimo że kryje się pod ostatnią literą nazwy).
W normalnej aplikacji to właśnie kontroler jest swoistą pierwszą linią w aplikacji:
- Przyjmuje dane przekazane przez użytkownika.
- Na podstawie parametrów pobiera informacje z bazy danych/serwisu.
- Dokonuje przetworzenia danych.
- Wypełnia model.
- Przekazuje model do widoku.
- Reaguje na interakcje użytkownika stymulowane z poziomu widoku.
To, co faktycznie robi kontroler, częściowo jest uzależnione od konkretnej implementacji.
Model
Dane przetworzone przez kontroler powinny trafić do modelu. Model przeważnie jest więc prostą klasą typu POCO (lub zestawem takich klas), która przechowuje przetworzone dane. W tego rodzaju klasach nie powinno być żadnej logiki biznesowej. Model jest przekazywany z kontrolera do widoku, co umożliwia obustronną komunikację między tymi elementami.
Model powinien być maksymalnie prosty, bez zbędnych elementów. Klasy użyte w modelu nie powinny być klasami, które są używane np. w ORM-ie do bazy danych.
Widok
Ostatnim elementem układanki jest widok. To właśnie do niego ostatecznie trafia klasa modelu. Widok odpowiada za:
- Wyświetlanie layoutu na podstawie modelu.
- Obsługę interakcji użytkownika i przekazywanie jego żądań bezpośrednio do kontrolera.
- Pobieranie danych wprowadzonych przez użytkownika w formularzu i przekazywanie ich dalej do kontrolera.
Widok nie powinien być z kolei odpowiedzialny za jakiekolwiek operacje na modelu danych.
ASP.NET MVC — najpopularniejsze „wdrożenie” wzorca MVC
Na podstawie powyższych informacji już w tym momencie moglibyście przygotować poszczególne elementy tej architektury. Należy jednak pamiętać o pewnej dość istotnej informacji — coś musi obsłużyć MVC. Mechanizmy do obsługi MVC bywają bardzo często dużo bardziej skomplikowane od samej architektury, dlatego warto, w miarę możliwości, skorzystać z gotowych rozwiązań.
Prawdopodobnie jednym z najpopularniejszych „wdrożeń” tego wzorca jest ASP.NET MVC. Warto przyjrzeć się tej technologii, ponieważ oferuje ona kilka interesujących rozwiązań, m.in. łatwą opcję wpięcia własnego kontenera IoC, wbudowany mechanizm routingu aplikacji czy też specjalną składnię Razor.
Szczegółowe informacje na temat ASP.NET MVC można znaleźć na oficjalnej stronie projektu: http://www.asp.net/mvc.
