Valaki letisztázná az MVC használatát phpban?

Én valahogy így képzelném el gombonyomástól kiíratásig:

Controller: Gombnyomásra a megfelelő esemény meghívása.

V

Model: SQL-ből az adatok lekérdezése.

V

View: Adatok megjelenítése (nyers szöveg megformázása).

Megnyomódik a gomb. A View jelzi a Controllernek, hogy gombot nyomtak, csinálni kéne valamit. A Controller a Model-hez fordul, mert SQL lekérdezésre lenne szükség. A Model lekérdezi az adatokat és visszaküldi a Controllernek. A Controller továbbküldi a Viewnek, hogy nesze, itt vannak az adatok, formázd meg és jelenítsd meg a usernek.

Azt hittem a model ismeretében egyértelmű hogyan gondolom a működést, de akkor talán így érthetőbb, ha az interakciókat írom le.

Itt találsz egy leírást is az MVC-ről:

[link]

Ne mások kódjait vedd alapul, hanem a model működését értsd meg.

A view fájljait is külön érdemes kezelni, ahogy a controller és model osztályokat.

Az én saját rendszeremben az előzetes feldolgozó részben a routing dönti el (a $_GET hívás alapján), hogy melyik controller illetve model osztályt kell meghívnia a rendszernek. A view pedig eszerint alakul.

Tehát nagyon fontos egy előfeldolgozó rendszer, ami az MVC-n kívül (felül) helyezkedik el, és a beérkező hívás alapján eldönti milyen struktúra hívódjon meg. Itt implementálhatod a rendszerkonstansokat, routingot, nyelviesítést, még az automatikus autorizációt is, és csak ezután kerül sor az mvc pattern által deklarált működésre, hiszen csak ez után tudja a rendszer, hogy mi a környezet (nyelv), mi a hívás, és ki a user.

A controller dönti el, hogy mely view osztályt hívja meg, hiszen egy hívás alapján a controller dönthet úgy, hogy nem létező adatokat hívtál meg, ezért az alap view hívás egy error kód view-ra állítja, stb...

Nagyon egyszerű szabály, hogy a controller állapítja meg mire van szükség, és mi "menjen ki". Tehát, ő hívogatja a modell osztályt, ami az adatbázis lekéréseket intézni, és ő adja át az adatokat a view osztálynak, ami a teljes html/css/js struktúrával echozza az infót.

A view nálam alapvetően úgy néz ki, hogy egy html keretbe (itt van a header, és minden ami a html struktúrához szükséges) hívja meg a megfelelő view osztályt, ami a kapott adatokkal a megfelelő struktúrát importálja.

Nincs "helyes" hasznalat, plane hogy amikor eloszor kitalatak akkor internet sem volt ergo hova rakod a DB kapcsolatot? Frameworkok is kulonbozokeppen ertelmezik, de nagyjabol:

Model:

Az adat reprezentalasa az applikacioban, semmi mas, nem kommunikal DB-vel

View:

Nem kommunikal semmivel, csak template-kent van hasznalva HTTP Response body renderelesere

Controller: Egy dolga van, fogadni a Requestet es visszakuldeni a Response-t

Request a bongeszobol->

Router (ami az url-bol +akar a request method-bol eldonti hogy melyik controller action kell meghivni)->

Middleware (pipeline amin vegigmegy a request pl: kell-e bejelentkezni az adott action eleresehez?, csak XMLHttpRequest engedelyezet? van-e form input? ha igen validalni kell )->

Contoller (ha kell fogja a DB layert(repository) es visszaker egy modelt, ha valamilyen szamolas kell akkor meghiv egy business layert aminek atadja a modelt, ha menteni kell a repository nem pedig a model)->

Response (Ha minden kesz a controller csinal egy response-t, parameterkent megadod a templated meg a modelt ami lerendeli a magat a response stringet)