Am rescris un articol mai vechi de pe blog, nu stiu cat de practic e sa iti implementezi asa ceva in propiu proiect dar mi s-a parut interesanta ideea la vremea respectiva, dintre framework-urile MVC cu care m-am jucat Symfony mi se pare ca mi se potriveste cel mai bine, imi place cum e documentat desi nu am reusit sa fac debug desi am instalat xdebug si am incercat cu PHPStorm.
1 Like
Imi pare rau dar asa ceva nu ar trebui sa mai fie promovat in 2020.
Daca vrei putem avea o discutie in privat in care iti spun si de ce este gresit sa spui ca PHP paote fi MVC (mai ales acea varianta din poza), si de ce nu este bine sa folosim MVC ca si structura de organizare.
Articolul initial a fost scris in 2013, am incercat sa reiau PHP de undeva, am lucrat cu PHP in facultate 2005-2006 am incercat sa fac un site de anunturi atunci, stiu ca de atunci a evoluat destul demult, nu stiu daca structura de organizare MVC ar fi gresita, avem ASP.NET MVC, solutia mea la nivel de cod e destul de simpla o organizare pe foldere si un routing, imaginea nu are acoperire completa in cod.
Daca vrei sa reiei php iti recomand :
https://www.php-fig.org/psr/ ca si standarde
http://www.slimframework.com/ ca si framework.
https://phptherightway.com/ ca si agregator de informatii.
De asemenea nu pot recomanda suficient urmatoarele tool-uri: Phpunit, Infection, Psalm/Phan
2 Likes
Ei na, cum adica “iti spun si de ce e gresit sa spui ca PHP poate fi MVC”. PHP e un limbaj iar MVC e un “design pattern” care poate fi implementat in aproape orice limbaj.
2 Likes
Uite aici o explicatie comprehensiva din 2013
Iar ca si referinte pentru ce spune acest blog uite ce spune creatorul MVC-ului:
http://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf
http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf
Iar legat de “design pattern”, MVC nu este design pattern ci arhitectura
1 Like
Interesant articol…
so let me get this straight, argumentul e ca “nu se incadreaza in definitia stricta a MVC”?
1 Like
Da. Daca nu se incadreaza in definitie nu este, altfel cadem in “las-o ba ca merge si asa” si ajungem la cazuri 787MAX.
mno, doar ca lucrurile evolueaza. cred ca un procent foarte mare din programatori inteleg altceva prin MVC. si in definitia lor se incadreaza. 
@IceRidder Am citit si articolul la care se face referire si cele date ca “suport” . Parerea mea e ca trebuie sa ii trimiti articolele tipului de la copernica sa aprofundeze domeniul. Sa le citeasca din punctul de vedere al celor care lucreaza cu frameworkuri server-side si o sa realizeze ca de fapt nu e nici o contradictie. Mai putin fata de constrangerile pe care EL le impune, nu standardul.
Si despre “design patern” :
Model–view–controller (usually known as MVC ) is a software design pattern…
Sursa: Wikipedia
@alexjorj pana in august 2019 wikipedia il categorisea ca ar chitectural pattern https://en.wikipedia.org/w/index.php?title=Model–view–controller&oldid=909234953 dar accept modificarea.
Legat de costrangeri, in documentatie scrie clar ca view-urile trebuie sa fie sincronizate si legate de model (care presupune ca atunci cand datele se modifica, view-ul trebuie sa se updateze, ceea ce cu php nu poti sa faci, doar cu js si websockets sau lucruri asemanatoare).
Chiar daca as accepta acest tip de MVC el este limitat si incomplet, spre exemplu in ce categorie intra un factory sau un repository? Daca vrei sa scrii cod de calitate (si aici intra toate limbajele nu doar PHP) trebuie sa urmaresti principille SOLID iar din start ceea ce vrea impune acest timp de MVC este acoperit de Single Responsability.
Datele nu se modifică la submit ? Nu le poți modifica după încărcarea paginii, deci din punctul ăsta de vedere datele sunt 100% sincronziate model-view. (întreb serios)
Da si nu. Documentatia spune ca ai mai multe view-uri legate de un model si fiind sincronizate trebuie sa se modifice toate. Initial MVC a fost creeat pentru GUI inainte sa avem back-end si front-end etc. Daca aveai 2 view-uri deschise, in unul ai in grafic si in altul ai un editor, cand modifici in editor se modifica si graficul din celalalt view.
ceea ce este perfect posibil si pe arhitectura clasica de web. inainte cu mici mari hackuri, acum mult mai simplu
Da dar nu doar din PHP. Asa cum am specificat ai nevoie de ceva gen websockets.
1 Like
Acum am înțeles problema: dacă ai două browsere deschise pe aceeași secțiune dintr-o aplicație, MVC s-ar ocupa de sincronizarea datelor din cele două instanțe. De asta ai spus că nu se poate fără sockets.
Dar…asta e, până la urmă, o limitare a browserelor, nu a unui limbaj anume. Că fix aceeași problemă o ai și cu py, Java sau go. Nu?
Vad ca zice si de GUI intr-o aplicatie de desktop. Acolo elementele din GUI(butoane, textbox-uri) sunt bind-uite la evenimente. Se asculta.
De exemplu pt WindowsForms.
private void button1_Click(object sender, System.EventArgs e)
{
//do magic here
}
The first parameter,
sender, provides a reference to the object that raised the event. The second parameter,e, in the example above, passes an object specific to the event that is being handled. By referencing the object’s properties (and, sometimes, its methods), you can obtain information such as the location of the mouse for mouse events or data being transferred in drag-and-drop events.
Mai este implicat(cred) si Observer pattern. Observatorii sunt notificati cu privire la un eveniment.
Nota: Events exista si in JS.
Cel putin asa stiu.
MVC poti avea si in JavaScript, asa cel putin vedeam AngularJS SPA, modificai view, ti se modifica $scope modelul, si ai si conceptul de controller, dar asta e MVC la nivel client side.
Cand faci web da dar daca faci desktop, mobile aps aceste limbaje teoretic pot aplica.