<p>Model-View-Controller to wzorzec złożony, którego przeznaczeniem jest podzielić aplikację na trzy odseparowane od siebie warstwy:</p>
<ul>
<li>Warstwę modelu: zawierającą bardzo często klasy POCO/POJO itp., oraz logikę biznesową.</li>
<li>Warstwę widoku: jest to po prostu interfejs użytkownika – wizualizacja danych z modelu.</li>
<li>Warstwę kontrolera: odbierającą żądania użytkownika(z widoku) i przekazującą je do modelu, oraz aktualizującą widoki.</li>
</ul>
<p>Konsekwencją tego mogą być luźne powiązania między klasami, większa przejrzystość kodu oraz możliwość jego wielokrotnego wykorzystania.</p>
<p>Model jest nieświadomy istnienia kontrolera i widoku. Widok zna (bezpośrednio lub pośrednio) model, ponieważ najczęściej bezpośrednio z niego otrzymuje informacje o stanie danych. Kontroler wie zarówno o modelu jak i o widoku. Poniższy schemat obrazuje relacje między warstwami w MVC. </p>
<img src="/static/img/blog/mvc.png" alt="" class=" postImage" />
<p><b>Model </b>można implementować, przy życiu wzorca <i><b>Obserwator</b></i>, jako element obserwowany. Obserwatorem jest widok(ale może to też być kontroler), który jest informowany gdy wizualizowane przez niego dane z modelu zmienią swój stan. Wykorzystanie wspomnianego wzorca pozwala na uniezależnienie modelu od widoków i kontrolerów, temu ostatniemu model udostępnia operacje pozwalające manipulować danymi, oraz odzwierciedlające logikę biznesową.</p>
<p><b>Widok</b>, jak już wspominałem, jest wizualizacją danych pochodzących z modelu, oraz interfejsem użytkownika pozwalającym na komunikację z programem. Często zdarza się że, gdy technologia na to pozwala, widok jest implementowany w sposób różniący się od reszty kodu – w ASP.NET korzystamy bezpośrednio z Razor’a, w WPF’ie z XAML’a, a w JavaScript’cie (np. w połączeniu z AngularJS) z HTML’a. Widok nie powinien (albo wręcz nie może) zawierać żadnej logiki. Chcąc umiejscowić widok wśród wzorców projektowych, można powiedzieć że jest to <b><i>Kompozyt </i></b>(korzystając z gotowych rozwiązań takie jak niektóre z wspomnianych przed chwilą, otrzymujemy narzędzia pozwalające tworzyć widok, zaimplementowane właśnie w postaci Kompozytu).</p>
<p><b>Kontroler </b>jest chyba najmniej docenianym elementem MVC, a pełniącym najważniejsze zadanie. Dzięki kontrolerowi model wie, że użytkownik coś zrobił, jednocześnie nie wiedząc nic o widoku :). Czyli kolokwialnie mówiąc rola kontrolera to bycie łącznikiem między widokiem a modelem. Kontroler jest Strategią widoku. Możemy zmienić zachowanie i możliwości programu po prostu zmieniając kontroler. Kontroler zawiera logikę sterowania programem (czyli np. może przechwycić zdarzenie z widoku i zinterpretować je na polecenie dla modelu), nie powinien natomiast implementować żadnych reguł biznesowych. </p>
<p>Jak widać koncepcja stojąca za MVC (jak i jego wariacjami) jest prosta jak przysłowiowa konstrukcja cepa. Miłej implementacji 🙂</p>