Tarkoitukseni oli siis kerrata viime postissa mainitsemastani PHP-raamatusta enterprise- ja tietokanta-patterneja. Eihän siitä mitään tullut! Olin läpikäynyt pari ekaa patternia näistä luvuista, ja olin tajunnut mikä Pröngissä minua nykyään häiritsee: se alkaa taas muistuttaa hallitsematonta sekametelisoppaa. Tämän syy on helppo jäljittää: liian lepsu arkkitehtuuri. Miksi dataolioiden pitäisi hakea tietonsa erilliseltä tietokantakerrokselta, kun tietokantaan pääsee käsiksi suoraan perimällä DB - luokan? Noh, olisiko yksi syy se, että oikeassa elämässä ei ole dataolioiden tehtävä tehdä muuta kuin pitää dataa sisällään!? Lisäksi esim. Luonnos - luokan määritelmä (class Luonnos extends DB{}) kuulostaa äärimmäisen typerältä! Luonnos is-a DB? Mikä pälli pitää ihmisen olla päästääkseen tällaistä laadunvalvontansa läpi!?
Ylemmät on kuitenkin helppo refaktoroida, mitä hittoa se onkaan suomeksi. Tämä onnistuu tekemällä Tehdas-luokka, joka sylkee ulos dataoliota samanlaisella rajapinnalla kuin vanhat dataluokat ovat luoneet itseään. Samalla voisi selkeyttää vanhaa tietokantarajapintaa joko tarjoamalla suoraan puolisuojattua PDO-liittymää tai toteuttamalla joku datamapperi (select()->from() - pattern) joko suoraan tekstipohjaisena (jolloin tämä olisi käytännössä puolityyppiturvallista SQL:ää) tai jollain jännemmällä tyypityksellä, jossa tietokantaan menevään SQL-lauseeseen ei ulkopuolelta pääse suoraan käsiksi, vaan se muodostetaan parametrina tulevien olioiden pohjalta.
Pröngissä minua häiritsee myös useat sisääntulopaikat. Jos oikein innostun, refaktoroin kaiken liikenteen kulkemaan index.php:n kautta, näin luoden hyvän Front Controllerin käyttöömme. Tämä ratkaisu vaatisi Command - patternin hyödyntämistä, jonka jälkeen komennot ja näkymät eivät enää olisi riippuvaisia URLin osoittamasta tiedostosta ja $_GETiä sekä $_POSTia sörkkivistä ehtopuista, vaan rakentaisin seuraavanlaisen systeemin:
- Request-luokan abstraktoimaan suoran $_GETin ja $_POSTin nätin rajapinnan taa
- CommandResolverin, joka palauttaa parametrina saamastaan Request - oliosta päätellyn läjän Command - olioita, jotka Front Controllerimme sitten ajaa
- Lopulta Controller päättelee Command - olioiden käsittelemästä Requestista ( tai jos loogisia halutaan olla, pitäisi varmaan muodostaa Response - olio) mikä näkymä ladataan
XML:ää sylkevät sisällöntuottajatkin vaatinevat vähän refaktorointia. Niille pitäisi tehdä oma kontrolleri, joka päättelee Requestin, eli URL-parametrien, perusteella A) mitä tuottajaa haetaan B) Mitä parametreja sille annetaan. Tällaisen rakennelman jälkeen pitäisi olla suhteellisen helppoa tuoda luonnostuottajan rinnalle esim. lautatuottaja, joka sylkee XML:nä dataa liittyen keskusteluihin, tai mahdollinen kalendaarituottaja tai profiilituottaja, jos tarve vaatii.
Tämän jälkeen pitäisi taas Pröngin koodailun olla kivempaa. Ties vaikka laudan uudelleenkirjoittaisi niin että se jopa toimii :)
No comments:
Post a Comment