fabercon.fi | 0400 533 978 tai 044 204 2029JavaFX MVVM-arkkitehtuurissamme on syytä korostaa serveripään tilattomuutta sekä tukeutumista Java EE:n standardi- ja ”best practise” -ratkaisuihin. Tilattomuus takaa siedon hyvin korkealle kuormitukselle.
Nykyisin HTML5-sovellukset ovat TSA-arkkitehtuurin mukaisia. Niissä tukena ovat Javascript-kirjastot, jotka vähentävät sovelluskoodia clientilla. Kattavimpia valmiita alustoja ratkaisuille ovat Oracle JET ja Angular 1 tai 2. Yhteyttä clientin ja serverin välillä hoidetaan RESTful-palvelujen ja JSON-tietotyyppien avulla.
Nyt ideana on siis säilyttää sovelluskokonaisuuden serveripään rakenne sellaisena, että siihen ei tarvitse tehdä muutoksia sen takia, että clienttina on web-sovellus, mobiili-sovellus, mobiiliweb-sovellus tai desktop-sovellus. Serveripäästä voidaan siis teknisesti tehdä täysin client-riippumaton.
JavaFX on natiivi ratkaisu sekä desktop- että mobiilisovelluksiin (ks. Gluon sivustoilta miten sama koodi soveltuu eri laitealustoille ja käyttöjärjestelmiin). Tämä tarkoittaa, että JavaFX sovellus kutsuu tilattomia RESTful-palveluita, ja tiedonvälittäjänä on JSON-data. Tämä on peruslähtökohta seppien JavaFX-MVVM-mallille. Se määrittelee kommunikaation serverin ja clientin välillä. Tilanhallinta on JavaFX:n clientilla luonnollista, kuten aina desktop-sovelluksissa.
Toinen merkittävä tekijä on MVVM-arkkitehtuurin tuomat vaatimukset. JavaFX on perusmuodossan MVC-mallin mukainen tekniikka, joten MVVM-arkkitehtuuri täytyy tehdä enemmän tai vähemmän koodaamalla (tätä kirjoittaessa ei ole mitään kunnollista ratkaisua yleisesti tarjolla).
MVVM-mallin keskeisimpiä tekijöitä ovat:
1. Kaksisuuntainen datan sidonta käyttöliittymän (komponenttien) ja sovelluslogiikan (datan) kesken. Tämä tarkoittaa, että kun muutat arvoja käyttöliittymässä tai koodissa, myös toinen päivittyy automaattisesti.
2. Sovelluslogiikan täydellinen riippumattomuus käyttöliittymästä. Tämä tarkoittaa, että kohdan 1 mukainen datan sidonta täytyy tehdä sovelluslogiikan ulkopuolella (tämä on osa käyttöliittymää). Ilman kohtaa yksi tätä kohtaa ei voi toteuttaa.
3. Testattavuus ilman käyttöliittymää. Testien kattavuuden takia on parempi, mitä ohuemmaksi testaamaton käyttöliittymä jää. Käyttöliittymän testaamisen automatisointi on hankalaa, mutta ilman sitä testaus voidaan automatisoida helposti. Tämä ei tietenkään rajoita itse käyttöliittymän testausmenetelmiä mitenkään. On helppo havaita, että ilman edeltäviä kohtia tämä kohta ei ole mahdollista.
Mitä vikaa on JavaFX:n perusarkkitehtuurissa? Ei välttämättä mikään, ja suositeltavaa on yksikertaisissa sovelluksissa käyttää vakiomuotoista MVC-arkkitehtuuria. Arkkitehtuurilla ei siis kannata ”ylirakentaa”. Kuitenkaan MVC-ratkaisu ei tuo edellä mainittuja etuja.
JavaFX kyllä omaa kohdan yksi kaksisuuntaisen datasidonnan. Sovelluksen alapuolinen kontrolleriluokka (nimi controller jo sinänsä viittaa MVC-arkkitehtuuriin). Mutta kontroller-luokassa esitellään käyttöliittymän .fxml-tiedoston näyttökomponentit ja sidotaan data ja komponentit keskenään. Sovelluslogiikka ei siis ole millään muotoa riippumaton käyttöliittymästä. Tästä seuraa, että sovelluslogiikkaa ei voi testata ilman käyttöliittymää. Kuitenkin, sovellusta voidaan testata ilman käyttöliittymän kuvaavaa .fxml-tiedostoa, joten testaus voidaan kyllä pitkälle automatisoida. Tämäkin osoittaa, että JavaFX:n standardiarkkitehtuurissa ei sinänsä ole mitään ongelmaa. JavaFX:n perusarkkitehtuurimalli on selkeämpi kuin .NETin WPF-sovellusten vastaava.
MVVM-malli puolestaan, myös seppien käyttämässä mallissa, vähentää riippuvuuksia osien välillä. Sovelluksen osien riippuvuuksien minimointi on avaintekniikka hallita monimutkaisia kokonaisuuksia. Käyttöliittymän ja sovelluslogiikan täydellinen erottaminen on tässä perustavanlaatuisin raja serveripään ja clientpään rajan jälkeen. Kuten myöhemmin nähdään, seppien ratkaisu takaa useita ylöspäin riippumattomia sovelluksen tasoja. Riippumattomuus tarkoittaa myös itsenäistä testattavuutta. Tämä on hyvä tarkistuskohta: voidaanko jokin osa testata ilman toista.
Seuraavissa blogeissa esittelemme sovelluksen tasot tarkemmin.
