Maailmad on erinevad: Model-View-Controller

Üks populaarsemaid kasutajaliides loomise mustreid veebirakenduste juures on Model-View-Controller ehk lühidalt MVC. Seda kohtame nii PHP, .NET, Ruby ja Java maailmas, kuid mõnes neist võib lähenemisnurk olla veidi erinev.

Liigume edasi nüüd mustri lahkamise juurde:

• Model –  Selle all mõeldakse tihtipeale ärimudelit, mis pole kõige valem, kuid parem oleks mõelda vaatemudelit. Põhjus on selleks lihtne – vaates võivad olla spetsiifilised väärtused kuvamise jaoks olla (n: mõne elemendi CSS klass) ning need ei peaks olema ärimudeli küljes. Lisaks võiks see sarnaneda võimalikult Data Transfer Objectile, mille teisendab Controller ärimudelist. Sel puhul ei peaks muretsema selle üle, et kui mingit meetodit või atribuuti kutsuda ei hakata andmebaasi vms kallale minema.
• View – Peamiselt HTML vaade kus seotakse andmed malliga. Teisisõnu lõpptulemus, mida kasutaja näeb.
• Controller – Küsib andmehoidlast vastava ärimudeli, käivitab vastavad äriprotsessid ja teisendab tulemuse vaatemudeliks ning kuvab vaate.

Tekkis väike kokkupuude Joomla!-ga ning ka seal on välja hõigatud, et kasutatakse MVC-d. Kõik tundus mõnus kuni reaalselt koodi tuli kirjutama hakata, sest sellega pandi mu arusaam mustrist kahtluse alla. Modeli tähendab seal hübriidi vaatemudelist ja andmehoidlast. Siinkohal võiksime apelleerida ActiveRecordi mustrile, et päringud ongi mudeliga koos, kuid siiski tegemist on vaatemudeliga ning reaalne ärimudel võiks olla sealne JTable objekt.

Järgmine oluline samm komponendi loomisel on Controlleri loomine, mis oli vägagi sarnane mu enda arusaamaga. Siiski väheke häiris mind see, et entry point tuli ise luua, mis võiks tähendada reaalselt FrontControllerit. Veidi mõistlikum viis oleks kasutada viidete reegleid (routing) Controllerite loomisel. Õnneks seal saab kasutada ühte ja sama faili erinevate komponentide tegemisel ning ise ei ole vaja väga leiutada.

Controlleri üks ülesanne on valida välja õige vaade (View). Vaated on tavaliselt HTML mallid, kuid sel puhul oli PHP fail ning vajas veel toimetamist. ASP.NET maailmas oleks samaväärne Code Behind fail, mis kahjuks oli tihtipeale prügikasti rolliga. Vaade laadis omakorda sisse reaalse malli (Template, Layout), mis kandis vaate tegelikke ülesandeid.

Segadust oli palju mustri väänamisega, kuid ei saa öelda, et see halvasti tehtud oleks, sest ma ei mõista veel kõiki tagamaid, mis otsuste langetamisel arvesse võeti. Soovitan teistel, kes loovad mõnda sarnaseloomulist raamistikku, siis kasutada mustreid nii nagu nad üldtuntuses on. Mustrite ülesanne on vähendada probleemi kirjeldamist ja lahendamist.

Loodetavasti mu kogemus aitab teil lihtsamini tutvust teha Joomla!-ga.