MVC-malliin perustuvien Javascript-sovelluskehysten vertailua. Jouni Kähkönen

Transkriptio

1 MVC-malliin perustuvien Javascript-sovelluskehysten vertailua Jouni Kähkönen Tampereen yliopisto Informaatiotieteiden yksikkö Tietojenkäsittelyoppi Pro gradu -tutkielma Ohjaaja: Timo Poranen Toukokuu 2014

2 ii Tampereen yliopisto Informaatiotieteiden yksikkö Tietojenkäsittelyoppi Jouni Kähkönen: MVC-malliin perustuvien Javascript-sovelluskehysten vertailua Pro gradu -tutkielma, 76 sivua Toukokuu 2014 Verkkosovellusten kehittämiseen on olemassa lukuisia eri Javascript-sovelluskehyksiä. Tämän tutkielman lähtökohtana on esitellä ja vertailla varteenotettavia MVC-sovelluskehyksiä keskenään. Tavoitteena on löytää kehysten laatuominaisuuksien pohjalta kuhunkin käyttötarkoitukseen parhaiten sopiva Javascript-sovelluskehys. Vertailussa on mukana kolme MVC-malliin pohjautuvaa sovelluskehystä: Maria, jquerymx ja KnockoutJS. Aluksi tarkastellaan verkkosovelluskehityksen taustaa ja käsitteitä. Tämän jälkeen esitellään sovelluskehysten keskeiset toiminnallisuudet. Esittelyn jälkeen kehysten ominaisuuksien pohjalta havaittavia arkkitehtuurivahvuuksia arvioidaan verkkosovellusten kehittämiseen liittyvien laatuominaisuuksien avulla. Arvioinnin jälkeen vertaillaan sovelluskehysten eroja sekä mahdollisia käyttötarkoituksia. Yleisesti voidaan havaita, että sovelluskehystä käyttäen verkkosovelluksen ohjelmakoodin laatu paranee ja ohjelmakoodin osien välinen sidoksellisuus vähenee. Vaikka sovelluksen ulkonäkö voi olla yhtenevä kehyksestä riippumatta, vaikuttaa valinta sisäisen arkkitehtuurin myötä koodin ylläpidettävyyteen, laajennettavuuteen, tehokkuuteen ja luettavuuteen. Kehysten tarkastelun pohjalta havaittiin sopivan sovelluskehyksen valintaan vaikuttavan ainakin kolme keskeistä tekijää: Pidettäessä koodin löyhää sidoksellisuutta tärkeänä päädyttiin suosittelemaan Maria-kehyksen käyttöä. KnockoutJS-kehystä päädyttiin suosittelemaan tapauksissa, joissa sovelluksen nopeaa kehitystyötä pidetään tärkeänä. Toisaalta vaillinaisen MVC-mallin toteuttavaa jquerymx-kehystä suositeltiin vain sovelluksiin, joissa MVC-mallin etujen tavoittelu projektin toteutuksen kannalta ei ole tärkeätä. Kehyksen käyttö ei kuitenkaan yksinään takaa sovelluksen korkeaa laatua. Esimerkiksi suorat ristiinviittaukset sovelluksen näkymän ja mallin välillä voivat vähentää ohjelman uudelleenkäytettävyyttä toisessa projektissa. Pelkkä hyväksi havaittujen suunnittelumallien seuraaminen ei siis johda onnistuneeseen toteutukseen. Kehittäjällä on oltava harjaannusta modulaarisen ja geneerisen koodin tuottamisesta sekä selkeä näkemys sovelluksen käyttöliittymän epäkohtien havaitsemisessa. Avainsanat ja -sanonnat: MVC, Javascript, suunnittelumallit, sovelluskehykset.

3 iii Sisällys 1. Johdanto Verkkosovellusten ohjelmistokehitys Yleistä verkkosovellusten kehityksestä Verkko- ja työpöytäsovellusten eroja Palvelinkeskeisyydestä asiakaskeskeisyyteen Sovellusalustan kehittyminen Käsitteet Kielet ja tiedonsiirtomuodot Verkkosovelluskehityksen yhteyskäytännöt Käyttöliittymän käsitteet MVC-malli ja sen johdannaiset MVC MVP MVVM Suunnittelumallit Oliomaailman käsitteet Javascriptissä Näkyvyys Rakennin Perintä Sovelluskehykset Yleistä sovelluskehyksistä Sovelluskehyksen käytön etuja Erilaiset sovelluskehysluokat Laatuominaisuusstandardit ISO ISO Keskeiset laatuattribuutit Laatuominaisuudet Sidoksellisuus Luettavuus Tehokkuus Siirrettävyys Ylläpidettävyys Laajennettavuus Koko Sovelluskehysten esittely Maria Framework jquerymx... 40

4 iv 4.3. KnockoutJS Sovelluskehysten arviointi ja vertailu Yleistä kehysten arkkitehtuurista Arviointi Maria Framework jquerymx KnockoutJS Vertailu Sidoksellisuus Luettavuus Tehokkuus Siirrettävyys Ylläpidettävyys Laajennettavuus Koko Vertailun yhteenveto Vertailun lopputulos Yhteenveto Viiteluettelo... 72

5 1 1. Johdanto Verkkosovellusalustan luonne on muuttunut viimeisen vuosikymmenen aikana merkittävällä tavalla. Ennen sivustot olivat staattisia, ja Javascriptillä lisättiin vain hieman vuorovaikutteisuutta sivuun. Vuorovaikutteisuuden vähyyteen vaikuttivat osaltaan Javascriptin universaalin tuen puuttuminen sekä se, että Javascript oli mahdollisuuksiltaan vielä melko rajoittunut. Yleensä sivustoilla käytettiin vain lyhyitä Javascript-koodipätkiä, eikä arkkitehtuurilliseen suunnitteluun koettu olevan laajemmin tarvetta. Lisäksi sivuston suorituskykyyn pyrittiin koneiden hitaampien tehojen vuoksi kiinnittämään enemmän huomiota tekemällä Javascript-koodista toteutukseltaan mahdollisimman yksinkertaista, käyttämättä sen koommin ylimääräisiä arkkitehtuurillisia kehyksiä avuksi. Tämä heikensi auttamatta myös koodin muokattavuutta. Tilanne palvelinpuolella on jo pitkään ollut paremmin hallussa. Arkkitehtuuriin on erilaisten sovelluskehysten avulla osattu kiinnittää huomiota aina sovelluksen kehityksen alusta asti. Asiakaspuolen koodiin eli käyttäjän selaimessa suoritettavaan ohjelmakoodiin ei välttämättä ole kuitenkaan ollut tarvetta kiinnittää huomiota, koska alkujaan koodi painottui selainpuolen koodin sijaan enemmän palvelinpuolelle, aiheuttaen sen, että selainpuolen koodista tuli usein yksinkertaista. Valitettavasti tämä käytäntö on osittain jäänyt edelleen vaikuttamaan verkkosovelluskehittäjien käytäntöihin asiakaspuolen koodin kehittämisessä. Verkkoselain on muuttunut staattisten sivustojen esitysalustasta merkittäväksi omaksi sovellusalustakseen. Tämän myötä ohjelmakoodin määrä selainpuolen sovelluksissa on lisääntynyt, ja samalla sovelluksista on tullut sisäisesti monimutkaisempia. Näin on syntynyt tarve kiinnittää huomiota myös asiakaspuolen koodin arkkitehtuuriin. Nyt arkkitehtuuriin panostamiseen on varaa, kun arkkitehtuurillisesta selainpohjaisesta koodista ei koidu välttämättä tuntuvaa haittaa sivuston tai verkkosovelluksen suorituskykyyn käyttäjien päätelaitteiden suorituskyvyn kasvettua. Suorituskyvyn nousun myötä on havaittavissa myös suuntausta, jossa sivuston osien asettelu keskittyy palvelinpuolen sijasta entistä enemmän selainpuolelle [Mesbah & van Deursen, 2007; Takada, 2014]. Näissä ratkaisuissa haetaan palvelimelta pelkästään raakadata, ja asiakaspuolella sijaitseva ohjelmakoodi rakentaa datan pohjalta haluamansa kaltaisen näkymän. Verkkosovelluskehittäjät toteuttavat verkkosovelluksia usein kunakin hetkenä ratkaistavaksi haluttavan ongelman viitekehyksestä. Sovelluksen muunneltavuus ja joustavuus kärsivät, kun sovelluksen perusarkkitehtuuriin ei

6 2 ole kiinnitetty huomiota sovelluksen suunnittelu- ja kehitystyön alusta alkaen. Lisäksi ketterän kehityksen kehitysmalli saattaa johdattaa verkkosovelluskehittäjiä ajattelemaan, että itse sovelluksen sisäiseen rakenteeseen ei ole syytä kiinnittää niin paljon huomiota kuin esimerkiksi sovelluksen ensi version nopeaan valmistumiseen. Sovelluksen kehittäjä ei näin ollen ota arkkitehtuurin tai sovelluskehyksen valinnassa huomioon sitä, että lähes kaikissa sovelluksen kehittämistapauksissa asiakas asettaa myöhemmässä vaiheessa muutos- ja päivitystarpeita sovellukselleen. Tämän tutkielman lähtökohtana on esitellä ja vertailla keskenään varteenotettavia MVC-sovelluskehyksiä ja pyrkiä löytämään sovelluskehysten laatuominaisuuksien pohjalta sopivin sovelluskehys Javascript-sovelluskehittäjien käyttöön. Erityinen painopiste vertailussa on kehyksen kyvyssä eriyttää datan käsittely, näkymä ja ohjelmalogiikka erillisiksi, mahdollisimman itsenäisesti toimiviksi kokonaisuuksiksi. Kehyksetön Javascript-koodaus, tarkoitukseen sopimattoman kehyksen käyttö tai kehyksen käyttö väärään tarkoitukseen saattaa johtaa koodiin, joka on siirrettävyydeltään, muokattavuudeltaan ja ymmärrettävyydeltään heikkoa. Toisaalta myös oikeantyyppisen Javascript-sovelluskehyksen löytäminen voi olla vaikeaa, joten on otettava huomioon kehysten eri painopisteet ja laatuominaisuudet, jotta kuhunkin tilanteeseen parhaiten sopiva sovelluskehys voidaan löytää. Luvussa 2 esittelen verkkosovellusten ohjelmistokehityksen taustaa sekä keskeisimmät selainpohjaisen ohjelmistokehityksen käsitteet. Selvennän myös, miten olio-ohjelmoinnista tutut käsitteet vastaavat selainsovelluksissa käytetyn Javascript-kielen prototyyppipohjaisia käsitteitä. Luvussa 3 kerron yleisesti sovelluskehyksistä, niiden eduista ja haitoista. Jaottelen myös selainpohjaiset sovelluskehykset eri sovelluskehystyyppeihin sekä esittelen sovelluskehysten vertailussa huomioitavat laatuominaisuudet. Luvussa 4 esittelen kolme verkkosovelluksien kehittämiseen käytettyä sovelluskehystä. Tuon esiin sovelluskehyksen MVC-mallin sovellustavan, kehyksen tyypillisimmät käyttötavat sekä omintakeisimmat sovelluskehyksessä esiintyvät piirteet. MVC-mallin käyttöä havainnollistan lyhyin koodiesimerkein. Luvussa 5 arvioin ja vertailen esitettyjä sovelluskehyksiä painottaen enemmän kehyksellä tuotettavien sovellusten koodirakenteellisia piirteitä kuin kehyksen omaa, sisäistä rakennetta. Lopuksi esitän yhteenvedon siitä, mitkä ovat keskeisimmät erot sovelluskehysten välillä ja mikä sovelluskehys sopii parhaiten kuhunkin käyttötarkoitukseen.

7 3 2. Verkkosovellusten ohjelmistokehitys Ohjelmistokehityksessä on usein kyse havaitun ongelman ratkaisemiseen tarkoitetun tietokoneohjelman suunnittelusta ja toteutuksesta. Verkkosovellusten ohjelmistokehitys rajautuu käsitteenä verkkoyhteyttä hyödyntävien sovellusten kehittämiseen. Tässä tutkielmassa ohjelmistokehityksen viitekehys rajautuu vielä verkkoselaimessa ajettavien sovellusten ohjelmistokehityksen tarkasteluun ja erityisesti verkkoselainpohjaisten sovellusten kehittämiseen käytettävien sovelluskehysten arkkitehtuurin arviointiin. Tässä luvussa kuvaan verkkosovellusten ohjelmistokehityksen ominaispiirteitä sekä keskeisiä verkkosovellusten kehittämisessä ilmeneviä käsitteitä. Kohdassa 2.1 käsittelen verkkosovellusten luonnetta, verkkoalustan yleistä arkkitehtuuria sekä verkko- ja työpöytäsovellusten eroja. Lisäksi pyrin luomaan kuvaa sovellusalustassa tapahtuneesta kehityksestä viimeisen vuosikymmenen aikana. Tämän jälkeen esittelen keskeisimmät selainpohjaisessa ohjelmistokehityksessä esiintyvät käsitteet (kohta 2.2), verkkosovelluksissa käytettävät MVC-mallit (kohta 2.3) ja suunnittelumallit (kohta 2.4) sekä lopuksi oliomaailman käsitteitä vastaavat Javascript-kielen tekniikat (kohta 2.5) Yleistä verkkosovellusten kehityksestä Verkkosovellusten ohjelmistokehitys pohjautuu perimmiltään palvelimen ja asiakkaan väliseen kommunikointiin. Lisäksi verkkosovellusten ohjelmistokehityksessä on kiinnitettävä erityistä huomiota sovelluksen tietoturvaan, sillä palvelin joutuu vastaanottamaan asiakkaalta dataa ja soveltamaan sitä käyttötarkoituksen edellyttämällä tavalla. Palvelimen ja asiakkaan välisessä kommunikoinnissa, niin kutsutussa palvelin asiakas-suhteessa, osa sovelluskoodista jakautuu palvelimelle ja osa käyttäjän selaimella suoritettavaksi. Lisäksi sivuston tai sovelluksen sisältö rakennetaan osin tai kokonaan palvelinpuolella, minkä jälkeen sisältö lähetetään käyttäjän selaimelle. Palvelin asiakas-malli mahdollistaa myös tarpeen mukaisen tiedon kätkennän: verkkosovellusten ohjelmistokehityksessä saatetaan jättää tärkeää sovelluskoodia, esimerkiksi yritykselle arvokas hintalaskufunktio, tarkoituksella vain palvelimella suoritettavaksi, sillä palvelimella sijaitseva koodi ei ole selaimesta käsin käytettävissä. Keskeiseen asemaan verkkosovellusten ohjelmistokehityksessä nousee palvelimella sijaitsevan koodin tietoturva. Mikään ei estä sovelluksen käyttäjää muokkaamasta selaimeen tuodun lähdekoodin sisältöä itselleen edullisella tavalla. Tämän takia palvelimella sijaitsevassa koodissa ei tulisi sokeasti luottaa

8 4 selaimelta tulevaan dataan, vaan kaikki tieto tulisi pääsääntöisesti sanitoida tilanteen edellyttämällä tavalla. Vaikka verkkosovellusten ohjelmistokehityksessä tiedon turvallisuuden tarkistuksen tarpeellisuus tiedetään jo laajasti, kuulee jatkuvasti uutisia verkkosovelluksiin kohdistuneista hyökkäyksistä, jotka johtuvat nimenomaan palvelimen vastaanottaman tiedon turvallisuuden riittämättömästä tarkistuksesta Verkko- ja työpöytäsovellusten eroja Verkkosovellusten ohjelmistokehitys eroaa jossain määrin työpöytäsovelluksiin liittyvästä ohjelmistokehityksestä. Verkkosovelluksissa alustana on käyttäjän selain, työpöytäsovelluksissa käyttöjärjestelmä. Useimmissa tapauksissa työpöytäsovellukset toimivat vain sillä alustalla, jolle ne on suunniteltu. Verkkosovellusten etuna on se, että ne ovat käytettävissä käyttäjän käyttöjärjestelmästä riippumatta, millä tahansa tuetulla selainalustalla. Toisaalta työpöytäsovellukset ovat usein suorituskyvyltään tehokkaampia, sillä sovelluksia voidaan lähes aina ajaa natiivisti suoraan tietokoneen suorittimella. [Bychkov, 2013] Työpöytäsovellusten ohjelmistokehitys eroaa myös asennustavaltaan ja päivitettävyydeltään verkkosovelluksista. Työpöytäohjelma on yleensä kehitettävä tiettyä käyttöjärjestelmää ja laitteistoa varten, ja se on niin ikään asennettava käyttäjän käyttöjärjestelmään. Ohjelmistoon tulevat päivitykset on myös asennettava jokaiseen asennukseen erikseen, kun taas verkkosovelluksissa päivitys joudutaan usein tekemään vain yhteen, palvelimella sijaitsevaan sovelluksen asennukseen. [Bychkov, 2013] Toisaalta verkkosovellukset näyttäisivät olevan ylläpidettävyydeltään häiriöalttiimpia kuin työpöytäsovellukset. Verkkosovelluksen käyttäjä on riippuvainen verkkosovelluksen palvelimen toimintavarmuudesta. Jos verkkopalvelin, jolle sovellus on asennettu, murretaan tai verkkopalvelin jumiutuu, mahdollinen käyttökatkos voi vaikuttaa kaikkiin kyseisen sovelluksen käyttäjiin. Tätä vaaraa ei ole verkkoyhteydestä riippumattomissa työpöytäsovelluksissa. Alkujaan tietokoneohjelmat toimivat suurten keskustietokoneiden alaisuudessa. Asiakaskoneet olivat vähätehoisia päätteitä, jotka käyttivät keskustietokoneen tehoja tiedonkäsittelyyn. Tietokoneiden suoritintehojen ja muistimäärän kasvettua alettiin tehdä yhä enemmän käyttäjän tietokoneen suoritintehoja ja muistikapasiteettia hyödyntäviä sovellusohjelmia. [Bychkov, 2013] Vastaavanlaista kehityskulkua näyttää esiintyvän myös verkkosovellusten ohjelmistokehityksessä; verkkosovellusten toimintalogiikka ei painotu nykyään enää niin paljon palvelinpuolelle, vaan sovelluksen käyttöliittymään ja tiedon

9 5 käsittelyyn liittyviä toimintoja suoritetaan yhä enemmän käyttäjän selaimessa, käyttäjän koneen resursseja hyödyntäen. Nykyään työpöytä- ja verkkosovellusten ero näyttää hieman kaventuneen. Verkkosovelluksia on mahdollista integroida yhä enemmän käyttäjän työpöytään: HTML5-standardin ja Javascript-kielen kehittyneiden tekniikoiden ansiosta verkkosovelluksiin pystyy esimerkiksi raahaamaan tietoa suoraan käyttäjän työpöydältä [Mozilla, 2014a]. Lisäksi on jo olemassa sovellusrajapintoja, joiden kautta verkkosovellus voi luvan saatuaan päästä käsiksi käyttäjän tiedostojärjestelmään [Html5rocks.com, 2014]. Tietyin tekniikoin on myös mahdollista ajaa verkkosovelluksia ilman selainta, omassa ikkunassaan [Sopyło, 2013; Adobe, 2014]. Lisäksi suorituskykyerot työpöytä- ja verkkosovellusten välillä ovat kavenneet. Alkujaan vain työpöytäsovelluksia ja muita paikallisia sovellusohjelmia ajettiin tietokoneen suorittimella natiivisti, mutta nykyisten kehittyneiden selainten komentosarjaesikäännöstekniikan ansiosta on niin ikään mahdollista päästä selainpohjaisilla sovelluksilla lähes natiivien sovellusten suoritustehotasolle Palvelinkeskeisyydestä asiakaskeskeisyyteen Ensimmäiset MVC-pohjaiset verkkosovelluskehykset keskittyivät usein niin sanottuun kevyeen asiakaspäätteeseen (engl. thin client), jossa lähes kaikki mallin, näkymän ja ohjaimen logiikka sijoitettiin palvelinpuolelle. Tällaista tekniikkaa käytettäessä käyttäjä lähettää joko hyperlinkkipyynnön tai lomakkeen syötteen selainpuolelta palvelinpuolen ohjaimelle, minkä jälkeen palvelin lähettää näkymänsä avulla selaimelle kokonaan päivitetyn verkkosivun. Selainpuolen ohjelmistotekniikoiden kehityttyä on tehty erilaisia selainpuolen sovelluskehyksiä, joiden avulla MVC-sovelluksen vastuualueet voidaan osittain tai kokonaan suorittaa asiakaspuolella. [Leff & Rayfield, 2001] Ohjelman toimintalogiikkaan liittyvän koodin painottuminen asiakaspuolelle on johtanut toimintojen vasteajan nopeutumiseen, kun sivuston muutosten näyttämiseksi käyttäjälle ei vaadita sivuston lataamista palvelimelta. Lisäksi vasteaikaa saadaan nopeutettua, vaikka tietoja jouduttaisiinkin lataamaan palvelimelta, sillä nykyaikaisten verkkosovellusten tekniikoilla palvelimelta voidaan ladata vain muuttunut osa sivustosta, tarvitsematta päivittää koko sivustoa uudelleen.

10 Sovellusalustan kehittyminen Vuosituhannen vaihteen alussa verkkosovellusten toteuttamisessa nojauduttiin vielä pitkälti selainlaajennusten tarjoamaan ohjelmistorajapintaan. Sovelluksia tehtiin paljon muun muassa Adobe Flash Player -selainlaajennuksen pohjalle. Lisäksi useat yritykset käyttivät selaimen laajennuksena toimivaa Java Applet -tekniikkaa sovellusratkaisuissaan. Tästä suuntauksesta aiheutui lukuisia sovelluksen käytettävyyteen ja siirrettävyyteen liittyviä ongelmia: verkkosovelluksen toimivuus oli kiinni selaimeen asennettavasta lisäosasta, jolloin sovelluksen käyttö esimerkiksi mobiililaitteilla tai vapaan lähdekoodin käyttöjärjestelmissä ei aina ollut mahdollista. Etenkin kannettavien laitteiden tehot eivät taanneet riittävän tehokasta Flash-suorituskykyä, tai laitteisiin ei sisällytetty ollenkaan tukea Flash-teknologialle sen hitaamman suorituskyvyn takia. Viimeisten vuosien aikana tällä saralla on kuitenkin havaittu positiivista kehitystä. Verkkosovellusten toteuttaminen selainlaajennusten varaan on huomattavasti vähentynyt. Tähän on merkittävästi vaikuttanut se, että suuret tietotekniikkayhtiöt ovat pyrkineet vähentämään ulkoisiin sovelluslaajennuksiin nojautuvaa sovellusten toteuttamiskehityssuuntaa ja sen sijaan olleet mukana HTML5-tekniikan eteenpäin viemisessä. Esimerkiksi Apple jätti kokonaan sisällyttämättä Flash-tuen matkapuhelimiinsa ja muihin mobiililaitteisiinsa muun muassa suorituskykyyn ja tietoturvaan liittyvin perustein [Jobs, 2010]. Näin verkkosivustojen toteuttajien on ollut pakko toteuttaa selainlaajennuksiin nojautuvat sivustotoiminnallisuudet uudelleen siten, että sivustot käyttävät natiivia HTML5-tekniikkaa selainlaajennusten asemesta. Tämä kehityssuunta vahvistaa HTML5-pohjaisten verkkosovellusten merkitystä. Tämän myötä myös sopivan Javascript-sovelluskehyksen valitsemisen tärkeys korostuu, kun tarjolla on lukuisia erilaisia sovelluskehyksiä erilaisine arkkitehtuuriratkaisuineen. Ongelmana on silti valinnan vaikeus: mikä kehys soveltuisi arkkitehtuuriltaan ja muilta ominaisuuksiltaan parhaiten kulloinkin suunnitteilla olevan sovelluksen toteutukseen. Lisäksi esiin nousee kysymys, kannattaako sovellus tehdä jopa ilman sovelluskehystä vai voiko kyseeseen tulla peräti oman yksinkertaisen sovelluskehyksen toteuttaminen. Ongelma on yhä ilmeisempi, kun yritykset vaativat tuoteratkaisuissaan työpöytäsovellusten sijaan enemmän selaimeen perustuvia käyttöliittymiä Käsitteet Tässä kohdassa esittelen keskeisimmät selainpohjaisessa ohjelmistokehityksessä esiintyvät käsitteet sekä merkittävät asiaa sivuavat tekniikat. Aluksi puhutaan yleisesti verkkosovelluskehitykseen liittyvistä kielistä ja tiedonsiirto-

11 7 muodoista. Sen jälkeen käsitellään sovellusten kehityksessä käytettäviä yhteyskäytäntöjä. Lopuksi tuodaan myös käyttöliittymää koskevat keskeiset käsitteet esiin, koska verkkosovelluksissa on loppujen lopuksi kyse käyttöliittymien rakentamisesta Kielet ja tiedonsiirtomuodot HTML-merkkauskielellä (engl. Hypertext Markup Language) esitetään verkkosivujen ja -sovellusten rakenne. Tässä hypertekstin luomiseen käytettävässä merkkauskielessä dokumentin rakenne kuvataan elementteinä, joiden sisällä voi olla toisia elementtejä. Elementtien ominaisuuksia voi tarkentaa elementtien tunnisteiden (engl. tag) sisällä määritetyin määrein (engl. attribute). Dokumentin rakenteesta voidaan viitata muihin dokumentteihin tai resursseihin käyttäen URI-viitteitä (engl. Uniform Resource Identifier) eli verkko-osoitteita. [W3C, 1999; Berners-Lee, 1989] Tiedon rakenteen ja sisällön esittämiseen ja siirtämiseen käytetään usein XML-kuvauskieltä (engl. Extensible Markup Language). Se on läheistä sukua HTML-merkkauskielelle, mutta sillä on eri käyttötarkoituksensa: uusia elementtejä voi määrittää ilman rajoituksia, ja elementeille voi antaa datan rakenteen asettamien vaatimusten mukaisia merkityksiä. XML:ssä tiedon rakenteen oikeellisuus on tarkempaa; esimerkiksi tunniste on aina päätettävä lopputunnistetta käyttäen, kun taas HTML-kielessä tietyt tunnisteet eivät vaadi lopputunnistetta. [W3C, 2008] XML on ominaisuuksiltaan monipuolinen merkkauskieli, mutta jossain mielessä myös hieman verboosi eli monisanainen: merkkaus voi viedä jopa enemmän tilaa kuin dokumentissa esitettävä data. Tämän ja muiden seikkojen takia on kehitetty muita, yksinkertaisia verkkosovellustekniikkoihin liittyviä tiedonkuvauskieliä. Eräs tällainen kieli on JSON (engl. Javascript object notation eli Javascriptoliomerkintätapa). Se kuuluu nykyään keskeisimpiin selainsovelluskehityksessä käytettäviin tiedonkuvaustapoihin. Tiedostomuodon kehittäjien mukaan kieltä on ihmisen helppo lukea ja tuottaa, mutta samalla koneiden helppo jäsennellä ja generoida. Sen avulla tietoa voidaan siirtää XML-kieltä yksinkertaisemmassa muodossa. Tallennusmuoto muistuttaa paljolti assosiatiivista tietotaulukkoa, sillä se koostuu kahdesta tietorakenteesta: a) luettelosta nimi-arvo-pareja, jotka ovat rinnastettavissa useissa kielissä olion käsitteeseen sekä b) järjestetystä listasta, joka muistuttaa perinteistä taulukkoa (engl. array). [JSON, 2014] Vaikka merkintätavan nimessä puhutaan oliomerkinnästä, JSON-muotoiseen dataan ei voi sellaisenaan tallentaa olioita. Oliot, kuten jopa yksinkertaiset

12 8 päivämäärätietueet, joudutaan sarjallistamaan merkkijonomuotoon, jotta tiedon tallennus JSON-muodossa onnistuu. Toisaalta tätä voinee pitää JSONmerkintätavan vahvuutena, sillä näin kyseisessä muodossa tallennettu tieto on kieliriippumatonta. HTML-dokumenttiin voi sisältyä myös selaimessa ajettavaa ohjelmakoodia. Tällöin kyse ei välttämättä enää ole dokumentista vaan selainpohjaisesta verkkosovelluksesta. Ohjelmakoodi voidaan liittää suoraan dokumentin rakenteeseen script-tunnisteella, tai koodi voidaan sisällyttää dokumenttiin viittaamalla erilliseen resurssiin. Yleisin verkkosovellusten selainpuolen ohjelmointikieli on Javascript, josta kerrotaan lisää kohdassa 2.5. Minimoinnilla (engl. minification) sovelluskehyksen koodi saadaan toimitettua usein yhtenä lyhennettynä komentosarjatiedostona, minkä ansiosta se saadaan ladattua nopeammin käyttäjän selaimeen verkkoyhteyden välityksellä. Minimoidusta lähdekoodista on poistettu tarpeettomat välilyönnit, rivinvaihdot ja sarkainmerkit sekä koodikommentit. Usein myös useampi komentosarjatiedosto on liitetty yhteen minimoituun komentosarjatiedostoon, sillä yhden tiedoston lataus vaatii useamman sijasta vain yhden http-pyynnön, mikä nopeuttaa sivuston latautumista entisestään. [Sahgal, 2014a] Minimointia ei tule sekoittaa obfuskointiin [JavaEncrypt, 2011] eli koodin monimutkaistamistekniikkaan, jossa varjeltavan lähdekoodin sisältö tarkoituksella sekoitetaan lukukelvottomaan muotoon [Sahgal, 2014b]. Javascript tulkattavana kielenä on otollinen minimoinnin käytölle. Koodia ei muunneta tavukoodi- tai binäärimuotoon, joten lähdekoodin koolla on merkitystä tiedonsiirron tehokkuudessa. Minimointi ei rajoitu vain ohjelmakoodiin; minimoida voi myös HTML- ja CSS-muotoista dataa. Keskeisenä käsitteenä ohjelmakoodin kannalta on DOM-ohjelmistorajapinta (engl. Document Object Model). Dokumenttioliomallin avulla selainpohjainen ohjelma pääsee käyttämään ja muokkaamaan HTML- ja XML-dokumenttien rakennetta. Rajapinta määrittelee tavan dokumentin tietojen hakemiseen ja muokkaamiseen. Dokumentti, niin sanottu DOM-puu, esitetään solmuina, joiden kautta komentosarjasta pääsee käsiksi dokumentin rakenteeseen. [Peltomäki & Nykänen, 2006] Ilman DOM-rajapintaa sovelluksen käyttöliittymäelementtien käyttö olisi hyvin vaikeaa, koska sovelluskehittäjän pitäisi itse jäsentää HTML-dokumentin sisältöä merkkijonodatana. On tärkeää huomata, että selainsovelluksissa DOMrajapinnan kautta käytettävä dokumentti vastaa sovelluksen näkymän rakennetta. Nykyään DOM-rakenteen muokkaamista voi helpottaa Javascript-kirjastoilla, kuten jquery [jquery, 2014].

13 Verkkosovelluskehityksen yhteyskäytännöt Yhteyskäytäntö on sovittu standardi laitteiden tai sovellusten välisessä yhteydessä käytettävistä keskustelusäännöistä. Yhteyskäytännön avulla mahdollistuu viestien lähettäminen osapuolten välillä. Verkkosovellusten tapauksessa käytetään niin kutsuttua http-yhteyskäytäntöä, johon kuuluu keskeisenä asiakkaan ja palvelimen eriytetty rooli. Yhteyskäytännön avulla sivusto voidaan ladata kokonaisuudessaan palvelimelta asiakkaalle, tai asiakas voi ladata dataa palvelimelta osittain, päivittämättä koko sivustoa. Asiakas on palvelimelta tulevan tiedon pyytäjä tai vastaanottaja, tai palvelimelle tiedon lähettävä osapuoli. Asiakkaana on usein selain, mutta se voi yhtä lailla olla jokin muu sovellus, joka käyttää palvelimen rajapintaa. Tässä asiakkaaseen viitataan selaimen lisäksi myös termillä selainpuoli. Pyynnöllä selain käskee palvelinta lähettämään resurssin sisällön tai muuttamaan resurssin sisältöä. Pyynnön mukana annetaan haettavan tiedon osoite eli URI-osoite, käytettävä metodi eli niin kutsuttu verbi, joita voi olla muun muassa GET, POST ja DELETE sekä mahdollisesti palvelimelle lähetettävä datan sisältö ja tyyppi. Pyyntö koostuu otsakkeesta (engl. header) ja runko-osasta (engl. body). Otsakkeessa on pyyntöön liittyvää oheistietoa, kuten käyttöjärjestelmäversio, selainversio ja viittaavan sivun osoite. [RFC2616, 1999] Palvelin vastaa pyyntöön vastaavanlaisella yhteyskäytännöllä. Vastauksen otsakkeessa on palvelimeen liittyviä tietoja, kuten palvelimen käyttöjärjestelmä ja versio sekä tiedon sisältöön liittyviä tietoja, kuten tyyppi, merkistökoodaus ja tilakoodi. Vastauksen runko sisältää pyydetyn resurssin tietosisällön, joka koostuu esimerkiksi verkkosivujen tapauksessa dokumentin HTMLrakenteesta. Runko voi puuttua vastauksesta, esimerkiksi palvelimen antaessa uudelleenohjauspyynnön. [RFC2616, 1999] Ajax-tekniikan (engl. Asynchronous Javascript and XML) avulla selainpohjaisen sovelluksen koodi voi hakea ja lähettää tietoja palvelimen ja selaimen välillä ilman koko sivuston uudelleenlataamista. Ajax-tekniikan avulla verkkosivujen vuorovaikutteisuutta voi lisätä. XML-muotoisen datan sijasta selain voi lähettää minkä tahansa muun tyyppistä dataa, kuten JSON-dataa. [Peltomäki & Nykänen, 2006] Tekniikkana Ajax on hyvin yksinkertainen; se ei sisäisesti paljon eroa normaalista http-pyynnöstä. Se kuitenkin avaa selainpohjaisille verkkosovelluksille lukemattomia mahdollisuuksia verkkosovelluksen vuorovaikutteisuuden lisäämiseen. Yleisellä tasolla kuvattuna Ajax-tekniikka mahdollistaa siirtymisen sivustomallista varsinaiseen sovellusohjelmamalliin, jolloin saavutetaan työpöytäsovellusta muistuttava käyttökokemus [Agile, 2013].

14 Käyttöliittymän käsitteet CSS (engl. Cascading Style Sheets) on merkkauskieli, jolla HTML-dokumentin elementteihin voidaan liittää tyylimäärittelyjä. CSS-kielen avulla sivuston tyylimäärittelyt saadaan erotettua HTML-dokumentin rakenteesta. Lisäksi samaa tyylimäärittelyä voidaan soveltaa useassa eri elementissä, mikä niin ikään lisää sivuston modulaarisuutta. [W3C, 2011] CSS on melko joustava ja monipuolinen merkkauskieli tyylien määrittelyyn, mutta sillä on heikkoutensa: Jos saman elementin tyylimäärittelyn alle määritetään muita tyylimäärittelyjä, joudutaan ulompi elementti määrittämään jokaisen alempana määritellyn tyylimäärittelyn yhteydessä uudestaan. Tämän ja lukuisten muiden CSS-kielen ongelmien korjaamiseksi on kehitetty useita kolmannen osapuolen tyylimäärittelykieliä, jotka yksinkertaistavat muun muassa sisäkkäisten tyylimäärittelyjen käyttöä. Nämä kielet kääntyvät joko ajon aikana tai ennen ajoa selaimen ymmärtämään CSSmuotoon. Esimerkkejä tällaisista käännettävistä tyylimäärittelykielistä ovat LESS [lesscss.org, 2014] ja Sass [Sass-lang.com, 2014]. Käytettävästä kehyksestä riippumatta verkkosovelluksen käyttöliittymät liitetään sovelluksen ohjelmakoodiin käyttöliittymätapahtumien avulla. Tapahtuma on välikappale käyttöliittymän ja sovelluksen toimintalogiikan välillä: järjestelmä kutsuu tiettyä sovelluksen funktiota tai metodia käyttäjän syötteen tai muun järjestelmän tapahtuman myötävaikutuksesta. Verkkosovelluksissa tapahtumafunktiolle annetaan parametrina usein event-olio, josta pääsee käsiksi tapahtumaan liittyvään käyttöliittymäelementtiin. Olion kautta saa myös tietoja tapahtumasta, kuten painetusta näppäimestä tai hiiren osoittimen sijainnista napsautuksen aikana. [Peltomäki & Nykänen, 2006] 2.3. MVC-malli ja sen johdannaiset Olennainen osa sovelluskehyspohjaista ohjelmistokehitystä on MVC-mallin käyttö. MVC-suunnittelumallin mukaan toteutettu sovellus eriyttää tiedonkäsittelyn, graafisen näkymän sekä ohjelmalogiikan toiminnallisuudet toisistaan. Tavoitteena on erottaa eri vastuualueet toisistaan, usein omissa luokissaan käsiteltäviksi, jotta ohjelman osa-alueiden riippuvuus toisistaan saadaan minimoitua. MVC-mallia ja sen johdannaisia kutsutaan esitysmalleiksi (engl. presentation pattern) [Manoj, 2012a]. Niiden avulla ohjelman tilan esitys saadaan eriytettyä ohjelman muusta toiminnasta. Useat esitysmallit ovat muunnoksia alkuperäisestä MVC-mallista.

15 11 Suunnittelumalleista ja MVC-johdannaisten malleista puhuttaessa on sekaannuksen välttämiseksi syytä mainita aiheeseen liittyvä suomenkielisen termistön monitulkintaisuus. Englannin kielessä suunnittelumallista (engl. design pattern) ja MVC:n mallista (engl. model) käytetään eri nimitystä. Tässä tutkielmassa MVC-mallilla tarkoitetaan nimenomaan MVC-suunnittelumallia, ei MVC-suunnittelumallin tiedonkäsittelystä vastaavaa mallia. Nykyisten verkkosovelluskehysten voidaan katsoa päällisin puolin toteuttavan MVC-mallin periaatteet. Kehysten MVC-toteutuksissa on kuitenkin paljon eroja ja jopa selvästi havaittavia puutteita. Jotkin kehykset käyttävät MVC-mallin asemesta jotain muuta esitysmallia, kun taas joidenkin kehysten kehittäjät väittävät kehyksensä toteuttavan MVC-mallin periaatteen, vaikka kehystä ei voitaisi selvästi kategorisoida mihinkään olemassa olevista MVCjohdannaisista. Esimerkiksi Backbone.js-kehys [Backbone.js, 2014] käyttää lähinnä MVPsuunnittelumallia tai jonkin asteen muunnosta tästä. Kehyksessä ohjaimen tilalla on niin sanottu esittäjä (engl. presenter), jolloin ohjaimen käytön sijasta ohjelmalogiikkaan liittyvä ohjelmakoodi siirtyy näkymän harteille. Esittäjänä kehyksen esitysmallitoteutuksessa toimii näkymään viittaava View-olio [Backbone.js, 2014], jolloin ohjaimen ja näkymän rooleja ei ole selkeästi erotettu. Osmani [2012b] toteaa, ettei kyseisen kehyksen arkkitehtuuri vastaa niin MVC-, MVP- kuin MVVM-mallia, vaan kehyksessä käytetään omaa, MV*-perhettä muistuttavaa arkkitehtuurilähestymistapaa MVC MVC-mallissa sovellus tai sen yksittäiset osat jaetaan malliin, näkymään ja ohjaimeen. MVC-mallin idean kehitti Trygve Reenskaug vuonna 1979 Smalltalk-ohjelmointikielelle. Alkuperäisen kuvauksen [MVC-Process, 2010] pohjalta uudelleenpiirretty kuva esittää tyypillisen mallin, ohjaimen, näkymän ja käyttäjän välisen vuorovaikutuksen (kuva 1). Käyttäjä vastaanottaa visuaalisia kuvia näkymältä, käyttää käyttöliittymässä esitettyjä ohjaimen toimintoja, jolloin ohjain muuttaa toiminnon edellyttämällä tavalla mallin tilaa. Malli vuorostaan tiedottaa tilansa muuttumisesta näkymälle (ja mahdollisesti muille mallin tilaa tarkkaileville olioille), jolloin näkymä päivittää käyttöliittymänsä vastaamaan mallin uutta tilaa. [Manoj, 2012a]

16 12 Kuva 1. Tyypillinen MVC-kiertokulku mallin, ohjaimen, näkymän ja käyttäjän vuorovaikutuksen välillä. [MVC-Process, 2010] Ohjain (engl. controller) vastaanottaa käyttäjän syötteen ja pyytää mallia hakemaan tai tallentamaan syötettä vastaavan datan. Syötteenä voi olla esimerkiksi painikkeen napsautus, tekstikentän muuttaminen tai mikä tahansa muu käyttäjän toiminto. Jos MVC-toteutus ei käytä tarkkailijamallia, ohjain itse pyytää näkymää esittämään datan. Tarkkailijamallia käyttävässä toteutuksessa mallin muutos aiheuttaa näkymän päivityksen. Ohjainta kutsutaan suomen kielessä myös käsittelijäksi tai kontrolleriksi. [Reenskaug, 1979; Manoj, 2012a] Malli (engl. model) sisältää sovelluksen datan tai on välillisesti yhteydessä sovelluksen dataan. Malli on usein passiivinen toimija; se hakee tai tallentaa dataa vain, kun ohjain (tai joissain toteutuksissa suoraan näkymä) käskee niin. Malli voi sisältää datan itsessään tai hakea sen jostain muusta lähteestä, kuten erillisestä tietokannasta. Kun mallin tila muuttuu, se käskee mallia tarkkailevia olioita, kuten näkymää, päivittämään tilansa muutoksen mukaisesti. [Reenskaug, 1979; Manoj, 2012a] Näkymä (engl. view) rakentaa käyttöliittymän esittäen suoraan mallilta tai ohjaimen välityksellä saadun datan käyttäjän ymmärtämässä, graafisessa muodossa [Reenskaug, 1979; Manoj, 2012a]. Lisäksi näkymä päivittää käyttöliittymää mallin muutosten mukaisesti sekä joissain tapauksissa erikseen ohjaimen käskystä. Joissakin verkkopohjaisissa MVC-ratkaisuissa näkymäksi kutsutaan HTML-dokumentin DOM-rakennetta, kun taas joissain ratkaisuissa DOM-rakennetta muokataan erillisen näkymäluokan (tai erillisten näkymäluokkien) kautta.

17 13 Reenskaug itse kuvaa mallin luontia seuraavasti: "MVC-mallista suunniteltiin yleinen ratkaisu ongelmaan, jossa käyttäjät joutuvat ohjaamaan suurta ja monimutkaista tietomäärää. Vaikeinta oli keksiä sopiva nimi arkkitehtuurin eri komponenteille. Model-View-Editor oli ensimmäinen nimeämiskäytäntö. Pitkien keskustelujen pohjalta, eritoten Adele Goldbergin kanssa, päädyimme ilmaukseen Model-View-Controller." [Reenskaug, 2014] Reenskaug suunnitteli MVC-mallin itse, mutta käytti sen ideoinnissa ja nimeämiskäytännöissä hyödyksi myös muiden tutkijoiden, kuten Adele Goldbergin, apua. Goldberg oli muun muassa Smalltalk-80-ohjelmointikielen oliokäsitteiden kehittämisessä mukana [Abbate, 2002]. Osmanin [2012b] mukaan MVC helpottaa sovelluksen toiminnallisuuksien modularisointia seuraavalla neljällä tavalla: 1) Ylläpito yksinkertaistuu, kun päivitysten yhteydessä kehittäjän on helppo päätellä, liittyykö muutos sovelluksen dataan, ohjelman toiminnan käsittelyyn vai käyttöliittymään. 2) Tiedon hakuun ja tallennukseen liittyvät yksikkötestit on helpompi toteuttaa, kun mallit ja näkymät on erotettu toisistaan selkeästi. 3) Matalan tason malli- ja ohjainkoodin toistoa saadaan vähennettyä. 4) Modulaarisuuden vuoksi sekä ohjelman ydinlogiikasta että käyttöliittymästä vastaavat kehittäjät voivat kehittää sovellusta yhtäaikaisesti. Keskeinen tavoite MVC-mallin arkkitehtuurin toteuttavalla sovelluksella tulisi tämän pohjalta olla vastuualueiden selkeä erottelu, toistuvan koodin välttäminen ja yhtäaikaisen kehitystyön mahdollistaminen. Tämän lisäksi tulisi MVC-mallin toteuttavien verkkopohjaisten sovellusten tarkastelussa erityisesti huomioida ohjaimen, näkymän ja varsinaisen käyttöliittymän välinen yhteys. Verkkosovellusten ohjain poikkeaa nimittäin toimenkuvaltaan työpöytäsovelluksissa käytetystä MVC-mallin ohjaimesta. Käyttöliittymätapahtumia ei voida verkkosovelluksissa suoraan liittää tiettyihin ohjaimen toimintoihin eli tapahtumankäsittelijöihin. DOM-elementti, johon tapahtuma liittyy, tunnistetaan kyseiseen DOM-elementtiin liitetyn id-tunnisteen tai class-luokkamäärittelyn perusteella, jolloin ohjain tulisi riippuvaiseksi käytetystä näkymästä, tai tarkemmin sanoen, näkymän käsittelemästä DOMhierarkiasta (ks. listaus 1). $('#okbutton').click(function() { console.log('ok- nappia painettu.'); }); Listaus 1. Ohjaimen tapahtumankäsittelijä tulee näkymästä riippuvaiseksi, kun HTML-elementin nimeen viitataan suoraan.

18 14 Jotta ohjain saataisiin näkymästä riippumattomaksi, tulee liitos ohjaimen toimintojen ja näkymän takana olevan DOM-elementin välillä ilmaista joko näkymän puolella [Michaux, 2013] tai erillisessä tapahtumankäsittelijäluokassa. Joka tapauksessa on otettava huomioon myös sovelluksen MVC-arkkitehtuurin lopullinen toteutustapa. Esimerkiksi deklaratiivinen ohjelmointitapa saattaa oleellisesti vaikuttaa käyttöliittymätapahtumafunktioiden ja DOM-elementtien yhdistämiseen liittyvään toimintalogiikkaan MVP MVP-mallin toteuttava sovellus koostuu mallista (engl. model), näkymästä (engl. view) ja esittäjästä (engl. presenter). MVP-mallissa perinteisesti ohjaimeen liittyviä tehtäviä on sijoitettu esittäjään, sillä näkymä on MVP-mallissa se sovelluksen osa, joka vastaanottaa käyttäjän syötteet. Näkymä ei kuitenkaan itse käsittele toimintoja, vaan pyytää esittäjää suorittamaan toimintoa vastaavan logiikan. Tähän voi sisältyä tiedon hakemista mallista tai mallin tiedon muuttamista. Pyydetyn toiminnon suorittamisen jälkeen esittäjä päivittää näkymän tilaa näkymän avaaman rajapinnan kautta, kuten kuvassa 2 on esitetty. [Osmani, 2012b] Kuva 2. MVP-mallin näkymän, ohjaimen ja esittäjän vuorovaikutus suhteessa sovelluksen käyttäjään. [Manoj, 2012b] Perinteisessä MVC-mallissa on muutama huono puoli: Ensinnä malli joutuu tiedottamaan näkymälle tilansa muuttumisesta. Toiseksi näkymän on oltava jossain määrin tietoinen mallista. Perinteisesti näkymän kuuluisi MVC-mallin mukaan toimia passiivisesti, "vain käskystä". MVP-mallissa näkymän ja mallin

19 15 välillä ei kuitenkaan tavallisesti ole erillistä rajapintaa, vaan esittäjä pyytää muokkaamaan mallin tilaa suoritettua toimintoa vastaavalla tavalla. Tällöin näkymästä saadaan passiivinen toimija. [Manoj, 2012a] Keskeinen idea MVP-mallissa liittyy näkymän vastuualueen rajaamiseen. MVP-mallin ideana on pyrkiä ratkaisemaan kaksi keskeistä perinteisessä MVCmallissa esiintyvää ongelmaa. Ensinnä malli joutuu tiedottamaan näkymille tilansa muuttumisesta. Toiseksi näkymä on täysin tietoinen mallissa. Näkymän tietoisuus mallista MVC-mallissa johtuu siitä, ettei näkymän ja mallin välillä ole erillistä rajapintaa. Tämän johdosta näkymä ei ole enää niin passiivinen kuin sen kuuluisi olla. [Manoj, 2012a] MVP-mallin tarkoituksena on mallin ja näkymän välisen välittömän suhteen erottaminen. MVP-mallissa näkymä julkaisee sovitun mukaisen rajapinnan esittäjälle. Kun käyttäjä on vuorovaikutuksessa näkymän kanssa, näkymä kutsuu esittäjän metodia, jolloin esittäjä suorittaa vaaditun tehtävän, kuten tiedon haun mallista. Tämän jälkeen esittäjä päivittää jälleen näkymää käyttäen näkymän sovittua rajapintaa. [Manoj, 2012a] MVP-mallin passiivisen näkymän tavoittelu saattaa monimutkaistaa sovelluksen käytännön toteutusta. Tämän vuoksi MVP-mallista on tehty kaksi eri versiota, joista toinen korostaa passiivista näkymää ja toinen aktiivisesti ohjaimen kaltaisena toimivaa näkymää. Näistä jälkimmäinen käyttää usein tietoliitoksia ja yksinkertaista koodia näkymän toimintojen toteuttamisessa. [Manoj, 2012a] Alkuperäisen kuvan [Manoj, 2012b] pohjalta uudelleenpiirretty kuva esittää perinteisen, passiivista näkymää käyttävän MVP-mallin toimintalogiikan (kuva 2). Aktiivista näkymää käyttävän MVP-mallin toiminta on muilta osin sama, mutta lisäksi näkymä on vuorovaikutuksessa mallin kanssa tietoliitosten kautta. Keskeinen ero MVP- ja MVC-mallien välillä liittyy ohjaimen ja esittäjän erilaiseen tehtävään. MVP-mallissa esittäjän tehtävä on esittää näkymältä saadun kutsun mukaisen toiminnon tila näkymän kautta käyttäjälle [Manoj, 2012a]. MVC-mallissa ohjain ei toimi mallin ja näkymän välikappaleena, sillä ohjain ei päivitä näkymän tilaa. Sen sijaan ohjaimen tehtävänä on toimia välikappaleena käyttäjän aikaansaamien toimintojen ja mallin välillä, kun mallin vastuulle jää komentaa näkymää päivittymään mallin nykyisen tilan mukaiseksi. MVP-mallia saatetaan käyttää pääosin yritystason sovelluksissa silloin, kun sovelluksen esityslogiikan uudelleenkäyttö on keskeistä. MVC-mallin käyttö ei tällöin välttämättä tule kyseeseen, sillä usein monimutkaisten ja paljon käyttäjävuorovaikutusta sisältävien sovellusten toteuttamisessa näkymä joutuu

20 16 olemaan vuorovaikutuksessa useamman ohjaimen kanssa. MVP-mallissa taas kaikki sovelluksen monimutkainen logiikka voidaan eriyttää esittäjään, mikä voi merkittävästi helpottaa muun muassa ohjelman ylläpitoa. [Osmani, 2012b] Esittäjä suorittaa sekä käyttöliittymätapahtumia vastaavan toiminnon että muokkaa käyttöliittymää toiminnon mukaisella tavalla. Täten MVP-pohjaisissa Javascript-sovelluskehyksissä sovelluksen näkymänä pidetään usein HTMLdokumentin DOM-rakennetta ja esittäjänä toimii olio, joka muokkaa käyttäjän syötteiden mukaisesti sovelluksen näkymän DOM-rakennetta MVVM MVVM on MVC-malliin pohjautuva suunnittelumalli, jossa arkkitehtuuri jakautuu malliin (M), näkymään (V) ja näkymämalliin (VM). Suunnittelumallissa näkymä ja malli ovat liitoksissa toisiinsa näkymämallin välityksellä (kuva 3). Suunnittelumallissa myös näkymällä on keskeinen rooli sovelluksen toimintalogiikan kannalta: näkymässä määritellään tietoliitosten avulla tapahtumia, jotka muuttavat mallin tilaa. Kuva 3. MVVM-mallissa näkymä on liitetty näkymämalliin tietoliitoksella, jolloin mallin data voidaan esikäsitellä näkymämallissa. [Mehran, 2010] Malli pohjautuu MVC- ja MVP-malleihin. Mallin tarkoituksena on erottaa ohjelman toiminta ja toimintaan liittyvä data selkeästi sovelluksen käyttöliittymästä. Aluksi MVVM-malli suunniteltiin Windows-käyttöjärjestelmän uudeksi käyttöliittymien mallinnukseen käytettäväksi alijärjestelmäksi, mutta myöhemmin mallia on sovellettu Javascript-pohjaisten sovelluskehysratkaisujen arkkitehtuurissa. [Osmani, 2012c] Mallin tehtävänä on muiden MVC-suunnittelumallien tapaan säilyttää ja käsitellä sovelluksen käyttötarkoitukseen liittyvää tietoa. MVVM-suunnittelumallin toteuttavassa sovelluksessa malli ei puutu sovelluksen toimintalogiikkaan eikä muotoile dataa millään tavoin. Ohjelman toimintalogiikka ja datan muotoilu kuuluvat MVVM-mallissa näkymämallin vastuualueeseen. [Osmani, 2012c]

21 17 MVC-mallin tapaan MVVM-mallissa näkymä on ainoa osa, johon sovelluksen käyttäjä on visuaalisesti yhteydessä. MVVM-mallissa näkymän tehtävänä on esittää näkymämallin nykyinen tila, ei suoraan mallin. Lisäksi MVVM-mallin näkymää pidetään aktiivisena toimijana, kun taas MVC-mallin näkymä on erillinen, passiivinen komponentti, joka ei itse ole tietoinen mallista. [Osmani, 2012c] MVVM-mallissa näkymässä määritellään tietoliitosten avulla sovelluksen toiminta sekä käyttöliittymätapahtumat. Käyttöliittymätapahtumaan liittyvä funktio voidaan suorittaa näkymämallin puolella, mutta näkymä on silti vastuussa sovelluksen toimintalogiikan mukaisesta tapahtuman liittämisestä oikeaan näkymämallin määreeseen. [Osmani, 2012c] Näkymämalli on vastuussa mallin tiedon muuntamisesta näkymässä esitettävään muotoon. Esimerkiksi tietokantamuodossa oleva päiväys voidaan muuntaa käyttäjän lokaalin mukaiseen muotoon. [Osmani, 2012c] Tässä mielessä näkymämalli on näkymän ja mallin välissä oleva muunninkomponentti, joka vastaanottaa dataa mallilta ja antaa sen näkymän käyttöön. Lisäksi näkymämalli voi muuttaa mallin tilaa, näkymästä annettujen komentojen perusteella. MVVM-mallissa näkymän tehtäväksi ei jätetä enää esitettävän tiedon muotoilua. Koska MVVM-mallisissa ohjelmissa mallista haettava data muotoillaan käyttäjälle näytettävään muotoon jo näkymämallissa, jää tältä osin näkymän tehtäväksi vain valmiiksi jalostetun tiedon esittäminen Suunnittelumallit Suunnittelumalli on ohjelmistosuunnittelijoiden hyväksi havaitsema tapa ratkaista jokin ohjelmistokehitystyössä usein esiintyvä ongelma. Suunnittelumalleja vastaavat toteutukset perustuvat nykyään yleensä oliopohjaisiin ratkaisuihin. Suunnittelumallien kuvaamiseen on kehitetty erilaisia valmiita kiinteitä malleja. Yleisimmässä tavassa esitellään suunnittelumallista neljä asiaa: ongelman nimi, itse ongelma, ongelman ratkaisu sekä siitä koituvat seuraukset. [Gamma et al., 1994] Suunnittelumallit ovat keskeinen osa verkkosovelluskehyksiä. Sovelluskehykset käyttävät usein useita suunnittelumalleja hyväkseen. Sovelluskehyksen käyttö on helpompi oppia, sillä sovelluskehittäjät tuntevat yleisimmät suunnittelumallit. Javascript-sovelluskehyksissä käytetään useita työpöytäsovelluksien kehittämiseen käytetyistä sovelluskehyksistä tuttuja suunnittelumalleja, kuten tarkkailija-, komposiitti-, strategia- ja tehdasmetodimallia. Näillä kaikilla on

22 18 keskeinen asema tasokkaan sovelluksen, ohjelmakoodin hallittavuuden ja yleisen arkkitehtuurillisen järjestyksen kannalta. Tarkkailijamallissa olio sisältää luettelon oliota tarkkailevista olioista, jotta muutoksen sattuessa oliossa voidaan tarkkailevia olioita, niin kutsuttuja tarkkailijoita (kuva 4), huomauttaa muutoksen tapahtumisesta automaattisesti, ilman tarvetta tietää tarkkailijoiden tarkkaa toteutusta. Alkuperäisen kuvan [Observer, 2010] pohjalta piirretystä tarkkailijamallin kuvauksesta (kuva 4) nähdään, että olion, jossa muutos tapahtuu, ei tarvitse itse päivittää muiden olioiden tilaa. Sen sijaan kukin olio huolehtii itse, kuinka reagoi tarkkailtavassa oliossa tapahtuneeseen muutokseen. Näin ollen tarkkailijamallia käyttämällä saadaan osien välistä sidoksellisuutta vähennettyä. Tarkkailtavaa oliota kutsutaan paitsi tarkkailtavaksi myös subjektiksi. [Gamma et al., 1994] Tarkkailtava Tarkkailija +päivitä() +tarkkailijat +lisäätarkkailija(tarkkailija) +poistatarkkailija(tarkkailija) +informoitarkkailijoita() informoitarkkailijoita(): for tarkkailija in tarkkailijat: call tarkkailija.päivitä() KonkreettinenTarkkailjaA +päivitä() KonkreettinenTarkkailjaB +päivitä() Kuva 4. Tarkkailijamallin arkkitehtuuri. [Observer, 2010] Pääasiallinen kommunikaatio MVC-mallin osien välillä tapahtuu tarkkailijamallin tai sen johdannaisen, kuten Public-Subscribe-mallin, toteutusta käyttäen. Siksi sitä pidetään tärkeimpänä MVC-mallin toteuttavan sovelluksen viestintätapana. Lisäksi tarkkailijamallin ominaisuudet mahdollistavat useamman mallin liittämisen yhteen näkymään MVC-mallissa. [Osmani, 2012b] Komposiittimallissa tietorakenne voi koostua pienemmistä osista, jotka taas voivat koostua pienemmistä osista. Mallissa toimenpiteitä voidaan suorittaa kerralla kaikille mallia käyttäville aliolioille, kun mallin kaikki osat toteuttavat saman rajapinnan. [Gamma et al., 1994] Strategiamallin avulla olion käyttäytymistä pystytään muuttamaan sovelluksen ajon aikana, jolloin olion toimintaa saadaan mukautettua itsenäisesti toisten olioiden käyttötarkoitusten mukaisesti. Strategiamallia käyttävä olio toteuttaa tietyn rajapinnan metodit, jotta oliota voidaan käyttää

23 19 tiettyyn käyttötarkoitukseen välittämättä olion yksityiskohtaisemmista metodimäärittelyistä. [Gamma et al., 1994] Tehdasmetodi on malli, jossa abstraktin funktiokutsun kautta luodaan uusia olioita. Tämä on mahdollista, kun olion kutsutapa on määritelty, mutta itse luokan ilmentymän luominen tapahtuu kokonaan aliluokan sisällä. [Gamma et al., 1994] Työpohjia (engl. template) käytetään muuttuvan näkymän sisällön runkona. Pohja määrittelee näkymän ulkoasun; muuttuville tiedoille on määritelty omat paikanvaraajansa, joihin kulloinkin esillä oleva data ilmennetään Oliomaailman käsitteet Javascriptissä Javascript on EcmaScript-nimisen tulkattavan funktionaalisen kielen eräs toteutus. Sitä käytetään enimmälti verkkoselainsovelluksissa ja ylipäätään verkkosivuilla. Kieltä pidetään perinteisesti tulkattavana kielenä, vaikka jotkin ympäristöt kääntävät Javascript-koodin ennen ajamista. Muita toteutuksia ovat muun muassa Microsoftin JScript [Microsoft, 2014] ja Google Chrome V8 [Google Developers, 2013]. Selkeyden vuoksi puhumme tässä tutkielmassa johdonmukaisesti Javascript-kielestä. Nimestään huolimatta kielellä ei ole yhteyttä Java-kieleen; nimi on valittu vain markkinointisyistä [Peltomäki & Nykänen, 2006]. Javascript-kielestä puuttuu kokonaan tuki luokkien käytölle; käytettävissä eivät ole perinteisistä ohjelmointikielistä tutut oliomaailman käsitteet, kuten rakennin (engl. constructor), purkumetodi (engl. destructor), luokkamuuttujien näkyvyys, luokkien perintä ja rajapinnat. Näiden sijaan perinteisiä olioita vastaavat prototyyppipohjaiset ratkaisut; oliot ovat funktioita, joiden sisällä on muuttujia ja toisia funktioita. [Peltomäki & Nykänen, 2006] Tästä voi koitua ongelmia, sillä suurin osa HTML-pohjaisista verkkosovelluksista toteutetaan juuri Javascriptiä käyttäen, vaikka yleisesti ohjelmistokehittäjät tuntevat luokkapohjaisen olio-ohjelmoinnin paradigman paremmin. Ratkaisuksi on kehitelty erilaisia Javascript-sovelluskehyksiä, joiden mukana tulee keinotekoinen tuki oliomaailmasta tutuille ratkaisuille. Nämä kehykset on toteutettu siten, että niiden käyttö ei vaadi lisäasennusta käyttäjän selaimeen, vaan kehys ladataan sivuston latauksen yhteydessä tavallisena Javascriptkomentosarjana. Seuraavaksi esittelen, kuinka Javascriptissä voidaan toteuttaa oliomaailmasta tutut käsitteet. Myös luokkapohjaisen oliomallin ja prototyyppipohjaisen ohjelmointitavan eroja käsitellään.

24 Näkyvyys Olion jäsenmuuttujien ja -funktioiden näkyvyyteen voidaan Javascriptissä vaikuttaa tiettyyn mittaan asti samantapaisesti kuin perinteisissä oliopohjaisissa kielissä. Näkyvyydessä on kyse luokan sisällä olevan jäsenen käytettävyydestä luokan ulkopuolelta käsin [Loudon, 2010]: Paikallista eli suojattua metodia voi käyttää vain luokan sisältä. Julkista jäsentä voi käyttää luokan ulkopuoleltakin. Näkyvyydestä puhuttaessa viitataan myös käsitteisiin tiedon kätkentä [Loudon, 2010] ja luokan tietojen kapselointi [Sommerville, 2010]. Kun muuttuja tai funktio liitetään olioon this-viitteen avulla, metodista tai muuttujasta tulee julkinen, eli siihen pääsee käsiksi myös olion ulkopuolelta (ks. listaus 2). function LuokkaA() { this.nimi = "Jouni"; this.teejotain = function() {}; } var a = new LuokkaA(); console.log(a.nimi); // Tuloksena "Jouni". Listaus 2. Julkisen jäsenmuuttujan käyttö olion ulkopuolelta. Kun muuttuja tai funktio liitetään olion sisällä käyttäen var-määrettä, funktioon tai muuttujaan pääsee käsiksi vain olion sisältä (ks. listaus 3). Toisaalta tällaisiin, paikallisiin muuttujiin pääsee käsiksi olion sisäisistä metodeista, kuten esimerkin saantimetodista annanimi(). function LuokkaB() { var nimi = "Jouni"; var teejotain = function() {}; this.annanimi = function() { return nimi; } } var b = new LuokkaB(); console.log(b.nimi); // Tuloksena undefined, määrittelemätön. console.log(b.annanimi()); // Tuloksena "Jouni". Listaus 3. Paikallinen jäsenmuuttuja ja -funktio. Sen sijaan suojattuja metodeja (engl. protected methods) ei voida perinteisin keinoin toteuttaa Javascriptissä. Suojatut metodit ovat käytettävissä luokan lisäksi luokan perineistä luokista käsin [Loudon, 2010]. On olemassa kuitenkin sovelluskehyksiä, jotka lisäävät tuen suojattujen metodien käytölle.