Temat: MVC - poszukuję materiałów...

Adam Brodziak:
Koncepcja MVC jest stara, stąd powstało wiele jej mutacji. Z tego co widzę we frameworkach PHP duży nacisk kładzie się na kontroler, za to np. w Rails mamy zasadę fat model - thin controller. Kluczowe jest zrozumienie wzorca (tyczy się to wszystkich wzorców), a nie "podglądanie" referencyjnej implementacji.

Zresztą, MVC wcale nie powstał dla aplikacji Web, ale to już zupełnie inna historia.

Zaciekawił mnie ten "gruby model" i "cienki controler". Mógłbyś to rozwinąć. Jaka część funkcjonalności można przenieść do modelu żeby nie zepsuć jeszcze MVC. Ja ostatnio pisząc w frameworku Code Igniter zauważyłem że mam dziwną tendencję przeciągania coraz więcej rzeczy do controlera. Może nie operacje bazodanowe, ale czasem nie chce się mi tworzyć nowego widoku aby coś wyrzucić na ekran i idę na skróty. Jak tak dalej pójdzie to zniknie mi gdzieś warstwa pośrednia.

Temat: MVC - poszukuję materiałów...

U mnie klasą pośrednią są pluginy . W klasie kontrolera tworzę obiekt weryfikacji dostępu i jeśli przejdzie pomyślnie , to tworzę obiekt pluginu , który z kolei wykonuje już sam swoje funkcje wyciągając dane z modelu i przekazując je do widoku .

Temat: MVC - poszukuję materiałów...

Jeśli chodzi o zasadę "fat model - thin controller", to po prostu DRY (ile tych genialnych skrótów sobie wszyscy wymyślają ;)). W modelu budujesz sobie schematy i reguły pobierania danych: wyciąganie ich z bazy, ewentualną obróbkę w PHP. Tak tworzone modele będą zawierały dziesiątki metod/funkcji, które pozwolą ci na ich późniejsze uniwersalne i szybkie wykorzystanie, bez powielania ich w kodzie setki razy. Musisz odnajdywać problemy, których rozwiązania dają się zamknąć w osobnym ciele i robić to. Nawet jeśli uważasz, że ten czy inny się już w aplikacji nie powtórzy, istnieje duża szansa, że na tym czy innym etapie rozwoju projektu to się właśnie zdarzy. A przecież nikt nie lubi wracać do starego kodu, a już mówienie o metodach typu kopiuj-wklej to dla wielu bluźnierstwo. Oczywiście wszedłem tu już w temat frameworkowych Helperów, ale koncepcja jest podobna.

Nie da się też ukryć, że opisywana zasada ma służyć odseparowaniu kodu sterującego aplikacją od wszystkiego innego. W najprostszym przypadku jest to instrukcja "case", która nie powinna mieć w swoim ciele napisanych z palca zapytań SQL, kilku pętli przekształcających dane w jakieś wymyślne drzewko na tablicach. Większość tego kodu można przenieść do Modelu.

Podsumowując, "fat model - thin controller" to:
- mniej kodu, mniej pracy (DRY),
- nie nachodzenie na siebie warstw aplikacji (łatwa modyfikacja, wyłapywanie błędów)Damian Tylczyński edytował(a) ten post dnia 17.12.07 o godzinie 18:00

Temat: MVC - poszukuję materiałów...

Adrian Zdziechowicz:

Adam Brodziak:
(...)
Zresztą, MVC wcale nie powstał dla aplikacji Web, ale to już zupełnie inna historia.

Z tego co pamiętam , to powstał w latach '70 do aplikacji pisanych chyba w Basic'u .

W Smalltalku. MVC to typowy wzorzec obiektowy, stąd dobra znajomość OOP jest potrzebna do jego zrozumienia. Często widzę opisy MVC, które z MVC mają wspólną jedynie ideę 3 warstw, a implementację są proceduralne (sic!).

Obiekt to nie jest zbiór atrybutów i metod. Obiekt to dostawca usług. To jest właśnie zmiana myślenia z proceduralnego na OOP. Polecam lekturę książki Wzorce projektowe. Analiza kodu sposobem na ich poznanie (lub chociaż udostępnionego pierwszego rozdziału). Ciekawą lekturą są także artykuły o RoR, można zacząć od 10 przykazań.

EDIT: Co do thin controller - fat model to właśnie w modelu ma być cała logika biznesowa aplikacji. Model to nie jest wartstwa dostępu do danych, coś takiego załatwia nam DAO, ActiveRecord, ORM itp. Kontroler służy jednynie do zarządzania pozostałymi komponentami, jak routing, ACL itd.Adam Brodziak edytował(a) ten post dnia 19.12.07 o godzinie 12:12