Deci in pula mea, eram ieri la servici, pe la pranz, si ma ia  A-C, sefa mea cu ea la etajul 1 (nu sa-i dau o muie cum poate va gandeati) ci pentru o “reuniune”. Reuniunea de fata insemna de fapt ca am intrat in biroul unuia si ne-am asezat pe niste scaune, el urmand sa ne prezinte, si apoi sa ne predea un maret backoffice de moderare. Backofficeul asta, teoretic, ar trebui sa ma scuteasca pe mine de sarcina de a scrie unul noul pentru proiectul la care lucrez, asa ca putea fi util, daca era adaptabil.

Ok, individul intoarce monitorul si ne arata cum se logheaza el, cu vede niste inregistrari, si le “modereaza”. Adica alege daca sunt spam sau nu, evident. Aplicatia are un aer invechit si arata destul de naspa, dar, ni se precizeaza, a fost utilizata intensiv de echipele care fac moderarea, deci sunt deja obisnuite cu modul de utilizare. In plus, si aici devin brusc interesat, este scrisa foarte curat, obiectual, si poate fi extinsa/adaptata usor pentru a obtine ce avem nevoie.
“Perfect”, imi zic, hai sa vedem codul ala. Reunionistul deschide pspad (intotdeaua mi s-au parut dubiosi programatorii care folosesc pspad, intre noi fie vorba), si imi arata structura de clase. “E arhitectura MVC”, ma asigura el triumfator.  Asa cum aveam deja sentimentul, mvc la el inseamna ca are un fisier, index.php, in care foloseste un switch pentru a selecta codul care se va executa. Exact asa si era …
Restul codului era intr-un folder separat de “clase”, si inca unul de “functii”. Ok, zic eu, arata-mi “clasele” tale.

Clasele erau de fapt bucati de cod care se executau pentru fiecare pagina a siteului, si care tratau tot fluxul, de la intrare pana la template-ul smarty. As face aici o paranteza, legat de smarty. Smarty este un cacat inutil, utilizat de fraieri ca sa dea impresia ca sunt mari programatori si separa “codul” de “view”. De fapt obti acelasi rezultat daca scri un template in php (php este in esenta pulii lui un limbaj de template-uri!) si ii pasezi argumentele intr-un array. La fel de usor ajungi sa bagi business logic in template si in smarty si in php. Si aici inchid paranteza.
Asadar, fiecare pagina avea codul ei,100 % procedural, jalnic inchis intre o declaratie de clasa si paranteza de inchidere corespunzatoare.
Dar asta nu e tot, continua programatorul. Exista si un (simulacru) de sistem de mostenire, pe un nivel: toate clasele mostenesc o clasa de baza pentru a mosteni niste functii comune (si destul de dubioase) de autentificare si acces la baza de date. Pentru ca, da, nici macar o abstractizare BD calumea nu a fost implementata, pentru ca, imi explica el usor jenat, nu a reusit sa gestioneze problema cele 2 servere BD (unul pentru citit, frontul si altul master, pentru scris). “Deci ai facut o treaba de cacat” imi zic eu in gand, apoi zambesc protocolar, pentru ca urma sa-l mai intalnesc pe individ la cafea.

Si acum partea didactica pentru toti pularaii care au deschis un editor si au inceput sa “programeze” in PHP, in principal pentru ca ca are  bariera de intrare foarte joasa.
In cuvinte simple, model view controller este un pattern care ar trebui in principiu sa izoleze logica aplicatiei, cum s-ar zice Business Model-ul, de interfata, de afisare. Asta inseamna ce … de exemplu daca ai de implementat afisarea listei de sefi carora trebuie sa le sugi pula ca sa ajungi un sef mai mic, in modelul aplicatiei incarci lista, din baza de date sa zicem, o prelucrezi, aplici reguli specifice (sa zicem ca ai o filtrare, numai sefi cu acelasi etaj cu tine sa va intalniti la aceeasi toaleta), dupa care pasezi aceste informatii, intr-un format neutru, afisarii. Si cine paseaza datele si face legatura intre model si afisare (view) ? Controllerul.
Aici este momentul in care fraierul cade in plasa … o regula foarte ignorata este TC-FM (thin controller – fat model), adica controllerul trebuie sa faca STRICT doar interfata intre cele 2, sa nu contina business logic. Dar, este mult mai usor sa bagi la greu cod in asa zisa ta “clasa” care devine un fat controller curand singleton curand o mare laba.
In poza de sus, in partea acoperita de pula, scrie “encapsulates application logic” si “exposes functionality”. Adica … adica ofera un acces selectiv la sistemul care e modelat. Deci fara query-uri in controller, desi pare mai usor. Izolarea scopului, asta e esential.
Muirea continua cu viewul: intr-o aplicatie web nivelul view este de fapt o combinatie intre codul server side care prepara afisarea, codul client side care o modifica/afiseaza (html + javascript care manipuleaza html) + browserul web, exact cois… Daca vrei sa fi ortodox nu faci query-uri in template-uri php sau altceva, nu prelucreazi informatie in view si nimic altceva. Doar afisezi, faci un for chestii de genu asta.
Mult mai ingrijorator este persistenta acestei abordari, daca pot macar sa-i zic asa, in framework-uri cu pretentii. Un trist exemplu este Zend Framework care nu ofera absolut nici un suport pentru partea de model, parca incearca sa fie o continuare a “traditiei” scriptkiddies legata atat de des de PHP.
Ca sa revin la intrebarea initiala: “unde pula mea e modelul?”

P.S.

Dupa amiaza m-am intalnit la o tigara cu Mikael, din celula de securitate, care mi- a zis ca cunoaste backoffice-ul respectiv, ca e “un truc de merde” dpdv securitate,  si tradus mai pe scurt, ca “isi baga pula, el nu aproba utilizarea lui in aplicatie”.