Akcja kontrolera, oprócz wydania rozkazu "przekaż te dane stąd dotąd", zarządza też paroma innymi zadaniami, których wymaga wygenerowanie strony. Dajmy na to autoryzację: może ona uruchamiać się automatycznie, po prostu dopasowując nazwę kontrolera i akcji do jakiegoś zbioru reguł w bazie danych i na podstawie tego określać, czy użytkownik będzie mieć dostęp. Są jednak sytuacje, gdy kwestia uprawnień komplikuje się na tyle, że ich obsługę musi jawnie zarządzić programista. Ponadto akcja to również komunikaty błędów, materiały dla widoku związane z "renderingiem" danej podstrony i kupa innych spraw, które nie zawsze powinny być duplikowane razem z właściwą częścią. Dlatego, gdy wiemy, że daną czynność należy wykonywać w kilku miejscach, powinniśmy powtarzający się kod wydzielić do osobnej klasy. Akcja w takim wypadku ustawiałaby wszystko, co niezbędne i konfigurowała obiekt tej klasy, mówiąc mu tylko, co ma zrobić. Taką klasę można by określić mianem zadania.
Zwróćmy też uwagę, że często kilka kontrolerów, wraz z innymi elementami, należy do tej samej grupy i w teorii nie powinny one funkcjonować niezależnie. Określimy ją mianem modułu, a za przykład może posłużyć np. moduł CMS. Zawiera on kontroler dla części publicznej serwisu, parę kontrolerów dla panelu admina umożliwiających zarządzanie treścią, jakieś modele itd. Jednak w nowym projekcie nie jest on nam potrzebny. Jeśli jawnie wprowadzimy moduły do naszego kodu (i zrobimy to sprawnie), możemy bardzo prosto pozbyć się CMS-a tam, gdzie go nie potrzebujemy. Co więcej, można napisać kilka modułów realizujących to samo zadanie, ale w inny sposób i programista mógłby szybko wybrać, który z nich jest aktualnie najbardziej adekwatny do potrzeb.
Tematyka ta zaczęła mnie nurtować z dwóch pośrednio nachodzących na siebie powodów. Po pierwsze, najnowszemu silnikowi sam MVC i parę innych wzorców za bardzo nie pomogło w ostatnim projekcie prowadzonym metodami "dziś ptaszek, jutro rybka" oraz "po co programista ma wiedzieć, co pisze" :). Mam silne podejrzenia, że również dla wielu publicznych frameworków byłaby to ciężka przeprawa. Z drugiej strony, potrzeba posiadania "kompaktowego", uniwersalnego silnika jest coraz większa. Nie chodzi nawet o same witryny internetowe, ale o różne wewnętrzne systemy z "webowym" interfejsem, które jakiegoś silnika też w końcu potrzebują, to nie żaden wyjątek. Racja, są gotowe frameworki i z jednego - Zend Frameworka - już nawet korzystałem w praktyce, ale z drugiej strony ich poznanie w stopniu wystarczającym do wyrażenia tego, czego potrzebuję, też wymaga czasu. Osobna kwestia to podpięcie OPT i OPF :). Ponadto pomysłów i umiejętności mi nie brakuje; wystarczy dobre rozplanowanie z odrobiną weny i kompletny kod może w kilka(naście) dni powstać od zera.
Tak czy siak każdy pomysł warto z kimś przedyskutować. Z chęcią poczytałbym w komentarzach, jak inni programiści radzą sobie z tego typu sytuacjami lub, jeśli implementowali podobne do moich rozwiązania, na co zwróciliby szczególną uwagę.
Napisał Ludvik w środę, 22 sierpnia 2007 o 21:34
Pisałem u siebie na blogu o oddzieleniu kontrolera autoryzacji od kodu akcji i myślę, że można usunąć kod odpowiedzialny za autoryzację z akcji, a bardziej wymagające fragmenty przenieść do helperów. Staram się też nie wiązać w żaden sposób widoku z akcjami. Wszystkie szczegóły widoku przenosimy do konfiguracji, jakieś szczątki kodu, instrukcje warunkowe można umieścić w szablonach. Akcje mają dostać parametry i zwrócić kolekcję obiektów, nie myśląc o widoku, a tym bardziej o użytym protokole. Kluczowe wzorce to Front Controller, Application Controller i Context Object. Postaram się napisać coś o tym szerzej na blogu, bo komentarz to trochę za mało.