Szablony i wzorzec MVC

Jarosław Zabiełło — Wed, 03 Jan 2007 20:30:00 +0100

Wzorzec MVC

MVC to skrót od ang. Model – View – Controler (czyli Model – Widok – Kontroler). Jest to jeden z popularniejszych wzorców projektowych (czy “wzorców architektonicznych w oprogramowaniu” jak się mogą czepiać niektórzy puryści) W uproszczeniu, wzorce projektowe to standardowe, sprawdzone rozwiązania dla typowych problemów programistycznych (głównie dotyczą programowania obiektowego). Ich przeciwieństwem są anty-wzorce, czyli to, jak nie należy programować. Typowym antywzorcem jest spaghetti-code, wymieszanie logiki biznesowej z warstwą prezentacji, wszystkiego razem w jednym śmietniku. To typowy styl programowania większości niedoświadczonych programistów PHP.

W skrócie, wzorzec MVC polega na takim podziale kodu, aby składał się z trzech, funkcjonalnie oddzielnych części.

Model

Modelem nazywamy tą część kodu aplikacji, która jest odpowiedzialna za kontakt z danymi biznesowymi, gdziekolwiek są składowane (zwykle w relacyjnej bazie danych). Model nie tylko służy do pobierania i modyfikacji danych biznesowych, ale także zajmuje się ich spójnością i integralnością poprzez odpowiednie mechanizmy walidacji danych. Model służy więc za zarówno strażnika jak i dysponenta danych biznesowych. Bardzo elegancko widać to w Ruby on Rails gdzie przykładowy kod pełniący rolę modelu wyglądać może tak:

class Project < ActiveRecord::Base
  belongs_to :portfolio
  has_one :project_manager
  has_many :milestones
  has_many :deliverables, :through => :milestones

  validates_presence_of :name, :description
  validates_acceptance_of :non_disclosure_agreement
  validates_uniqueness_of :short_name
end

Widok

Widok służy do generowania tego, co moglibyśmy określić jako prezentację naszej aplikacji. Przy czym nie jest określone jak ta prezentacja ma wyglądać. Ogólnie prezentacją jest to wszystko, co aplikacja “wypluwa” na zewnątrz. Nie musi to być żaden “interfejs użytkownika” jak wypisują bzdury co niektórzy. Model MVC nie zakłada przecież tego, kto ma być odbiornikiem wysyłanego strumiena danych. Może to być zarówno pani Genowefa miotająca się po internecie za pomocą Internet Explodera jak i rozbudowany czytnik kanałów RSS, albo jakieś dowolne urządzenie odbierające generowany strumień danych (w tym ostatnim wypadku nie musi to być w ogóle aplikacja webowa) Generowany strumień danych nie musi być w ogóle żadnym tekstem. Mogą to być bowiem równie dobrze strumień danych binarnych.

Zresztą tak właśnie działają aplikacje webowe, które działają wg zasady client-server. Tzn. klient wysyła żądanie, a serwer odpowiada. Przeglądarka Iinternetowa wysyła żądanie do serwera WWW, a on odpowiada jej strumieniem danych. (w wypadku aplikacji webowych serwer wysyła wpierw tekst z nagłówkiem informującym co będzie wysyłane, bo to wynika z zasad protokołu HTTP).

BTW, z tego wynika ważna lekcja odnośnie adresów URL. To co wklepujemy w przeglądarce nie musi mieć żadnego związku z jakimikolwiek ścieżkami na serwerze. Wszystkie technologie, używające jawnych rozszerzeń plików (.asp, .php, .jsp, .aspx itp) są głupie, bo po pierwsze, sugerują że to coś w adresie z końcówką .php to zawsze jest konkretny plik po konkretnym katalogu. Po drugie, bez sensu eksponują użytą technologię, co wiąże trochę ręce tym, którzy by chcieli zmienić wewnetrzny system generujący strony WWW ale bez ruszania starych adresów URL. Po trzecie, spidery takie jak Google nie lubią indeksować stron generowanych dynamiczne. Jeśli zobaczą w adresie znak zapytania to najczęściej to, co za nim stoi jest ignorowane. Odbija sie to na “pozycjonowaniu” tak napisanej aplikacji. I po czwarte takie adresy (z rozszerzeniami i parametrami po znaku zapytania) są najzwyczajniej brzydkie i trudne do zapamiętania. Nie znaczy to, że tak (/?x=1&y=2&z=4)w ogóle nie przekazywać parametrów. Chodzi tylko o to, aby to robić to oszczędnie i tylko wtedy, kiedy jest to naprawdę koniecznie.

Kontroler

Kod, który spina wszystko razem i stanowi serce aplikacji to kontroler. To on pobiera dane z bazy za pomocą modelu i to on wybrane dane wysyła do widoku aby je jakoś zaprezentował dla odbiorcy. Kontroler także dba o takie kwestie jak autoryzacja i autentykacja użytkowników (określa kto może mieć dostęp do poszczególnych części aplikacji). Kontroler zajmuje się też sposobem przepływu danych zgodnie z potrzebami logiki biznesowej.

Szablony i Helpery

Czym są szablony? Szablony przynależą do warstwy Widoku wzorca MVC. Otrzymują dane z kontrolera i na tej podstawie generują kod HTML jaki jest wysyłany do przeglądarki. Szablony powinny być raczej proste tak, aby można było łatwo modyfikować sposób prezentacji bez godzin ślęczenia nad kodem. Najczęściej kwestią prezentacji zajmują się różnej maści webmasterzy i designerzy, czyli ogólniej osoby, które niekoniecznie są zaawansowanymi programistami.

W wypadku kiedy sposób prezentacji jest złożony, aby nie komplikować szablonu stosuje się do pomocy… pomocnika ;) Głównym zadaniem helpera jest takie wstepne przetworzenie danych (jakie kontroler wrzucił do szablonu) aby szablon mogący je wyświetlić był jak najprostszy i jak najbardziej czytelny. Helper dane pobiera od szablonu, modyfikuje je i odsyła je z powrotem. Dzięki temu logika niezbędna do wygenerowania prezentacji jest w szablonie znacznie uproszczona.