Keskustelu: Nettisivujen teko: MVC-arkkitehtuurista

CodeIgniteria olen tässä opetellut käyttämään (ja on muuten varsin näppärä php framework)... Pari asiaa minua on kuitenkin alkanut mietityttämään MVC-arkkitehtuuriin perustuvien sovellusten toteutuksesta. Noin yleisesti ottaen kannattaako yhtä sovellusta esim. blogia varten luoda useampi kuin yksi malli tai ohjain? Eli onko enää tällä tasolla syytä hajauttaa toimintoja useampaan eri osaan?

Tietty tämä voi olla aika sovelluskohtainen asia...

Kysymyksesi on hieman hassusti aseteltu. Toivottavasti et ole käsittänyt mitään väärin: MVC ei suinkaan tarkoita, että ohjelmassa olisi tasan kolme osaa, vaan kyse on järjestelmän toiminnan kerroksista. Tietenkin kaikki kerrokset on jaettu modulaarisesti loogisiin osiin, kuten ilmankin MVC-mallia.

Joo myönnetään, että tuo viesti oli vähän hölmösti kirjoitettu (kello oli jo aika paljon :D).

No, okei testataan tätä mun ymmärtämistä. Jos oltaisiin tekemässä nyt sitten vaikka sitä vieraskirjaa, niin kävisikö tälläinen eri kerroksien hajautus:

Ohjaimet:

- Vieraskirja
- Hallinta

Mallit:

- Vieraskirja_malli
- Hallinta_malli

tai vaihtoehtoisesti

- Data_malli

Näkymät:

- Lue_viestit
- Kirjoita_viesti

- Vastaa_viestiin
- Poista_viesti

Eli vähän suuntaa haen sille, että mikä nyt sitten on looginen kokonaisuus ja mikä ei...

Teet asiasta aivan tarpeettoman mutkikkaan. Vieraskirjan tapauksessa malliksi riittää yksinkertainen rajapinta, jolla viestejä voi lisätä, poistaa ja lukea. Näkymiä voi tehdä yhden tai kaksi; itse tekisin vain yhden näkymän, jossa sitten ehtolauseella määritellään, tulostetaanko poistolinkit viestien viereen. (Toki jos tehdään erillinen hallintasivu, joka näyttää ruudullakin aivan erilaiselta, uusi näkymä on selvästi perusteltu.) Näkymän voi halutessaan jakaa useampaan osaan, jos esimerkiksi samanlainen viestilistaus on tarpeen toisessa paikassa mutta listan alla oleva laatikko ei. Toisaalta tämän voisi toteuttaa näkymäjärjestelmän sisällä niin, että näkymä "vieraskirja" toteutettaisiin tulostamalla peräkkäin näkymät "viestilista" ja "kirjoituslaatikko".

Ohjaimen toteutus onnistuisi näillä eväillä suunnilleen näin helposti:

<?php
// Ohjain...
// - vastaanottaa käyttäjältä tulevat käskyt:
if (!empty($_POST['viesti'])) {
    Viesti::lisaa($_POST['viesti']);
}
if (!empty($_POST['poista']) && $admin) {
    Viesti::poista($_POST['poista']);
}

// - ohjaa näkymää:
$parametrit = array(
    "viestit" => Viesti::kaikki(),
    "admin" => $admin
);
nakyma("vieraskirja", $parametrit);

MVC ei ole kummoinen keksintö: se on vain tapa jäsennellä ohjelmaa. Lopputulos on suunnilleen MVC-mallin mukainen jo sillä, että tietokannan käsittelyn ym. toiminnallisuuden kirjoittaa yhteen paikkaan ja ulkoasun toiseen paikkaan, minkä jälkeen varsinainen ladattava sivu (nyt vaikka vieraskirja.php) sisältää enää funktiokutsuja ja sellaisia yksinkertaisia toimintoja, jotka liittyvät syötteiden tarkistamiseen tai ovat välttämättömiä näkymän ohjaamiseksi. Vieraskirjan kohdalla nämä ovat minusta melko selkeitä.

Mutkikkaissa sovelluksissa on joskus vaikea päättää, mille tasolle jokin toiminto kuuluu. Tällaisissa tilanteissa on kolme vaihtoehtoa: Toiminnon voi vain laittaa jonnekin, jolloin järjestelmä toimii mutta epämääräinen ratkaisu jää ehkä perfektionistia kaivelemaan. Toisaalta toiminnon voi yrittää jakaa täsmälleen MVC-mallin mukaan, jolloin sen vaatima koodimäärä saattaa kaksinkertaistua tai enemmänkin, ja jos kyseessä on kriittinen osa järjestelmää, myös hitaushaitta voi olla huomattava. Kolmas vaihtoehto on tietenkin perustella itselleen ja työkavereilleen, miksi nämäkin toiminnot oikeastaan kuuluvat ihan oikeasti tiettyyn paikkaan, jolloin pääsee yhtä helpolla kuin ensimmäisessä tapauksessa ja ilman tunnonvaivoja. ;)

Kiitos tästä! Mulla on vaan aina tapana ajatella asiat kaikkein vaikeimman kautta (miestä lie tollanenki tapa tullu). Kun oppis vielä käyttämään UML-mallinnusta, niin voisi ohjelmien suunnittelukin olla helpompaa...

Heräsi tässä vielä kysymys... Eli minkälaisessa tilanteessa kannattaa luoda täysin uusia luokkia, mitkä eivät ole millään tavoin periytyneet esim. mallista tai ohjaimesta? Vai onko kysymys lähinnä siitä, että kun halutaan luoda enemmän yleiskäytettävää koodia (kuten helppereitä), niin silloin se erotellaan omaksi luokaksi? Itse käsitin lähinnä niin, että nuo mallit ja ohjaimet ovat ikäänkuin "ohjelmakohtaiset", kun taas noita luokkia ja helppereitä voi soveltaa ohjelmaan kuin ohjelmaan... korjatkaa jos olen käsittänyt väärin.

"Periytetty mallista tai ohjaimesta", mitä? Mallit, ohjaimet ja näkymät ovat abstrakteja käsitteitä, joilla ei ole fyysisesti sijaa itse ohjelmassa (ellei jokin frameworkki ole keksinyt tähän jotain kummallista vaatimusta). Toki perinnöllisyyttä ja vakioituja rajapintoja voi hyödyntää, mutta esimerkiksi mallin kohdalla sama rajapinta kaikelle ei tule kyseeseen, koska eri osien toiminnot ovat erilaisia.

Jos otetaan ihan konkreettinen esimerkki, niin työprojektissani on malli sisältää parisataa luokkaa, ohjain reilut satakunta, ja jokaista ohjaimen osaa vastaa suunnilleen yksi näkymän osa. Suurin osa koodista on täysin projektikohtaista; kunnolla uusiokäytettävää materiaalia olisivat lähinnä muutamat tietokantarajapintaan, lokalisointiin ja syötteiden tarkistukseen liittyvät toiminnot.

Kuulostaa, että jos yrität väkisin koodata MVC-mallin mukaan, päädyt virittelemään jotain todella hankalaa ja omituista. :) Ehkä paras lähestymistapa aiheeseen nyt olisi, että tekisit jonkin ohjelman hyvien koodaustapojen mukaan eli niin, että käyttöliittymä, toiminnot ja back-end olisivat toisistaan erillään. Lopuksi voisit sitten katsoa, mitä tuli tehtyä ja miten lopputulos suhtautuu tähän MVC-malliin. Parin yrityksen jälkeen luultavasti ymmärrät asiasta paljon enemmän kuin parin päivän teoriakeskustelun jälkeen. Voit ensin kokeilla vieraskirjaa ehdottamallani rakenteella, ja sen jälkeen kannattaa valita jokin tasoltaan vastaava projekti, jossa kuitenkin olisi useampi osa-alue (esim. foorumilla käyttäjät, alueet, aiheet ja viestit).