info  fabercon.fi | +358 400 533 978 or +358 44 204 2029

Sovellusarkkitehtuurimallit Web-sovelluksessa

Yhteistä yleisille arkkitehtuurimalleille (MV*):
Kaikissa malleissa on ideana järkevät riippuvuudet eri osien välille ja selkeät ohjeet, mitä kukin sovelluksen osa tekee. Kaikissa on Model riippumaton muista osista. Tärkeintä on, että käyttöliittymä (View) ja logiikka (Model) ovat selkeästi erillään. Kun kyseessä on web-sovellus, on termi Model sisällöltään kaikkea muuta kuin kiinteä, se voi sisältää logiikkaa, palvelukutsuja ja tietokannan hallintaa.

Nämä mallit eivät tietenkään ole sidottuja vain web-sovelluksiin, vaan niitä voidaan käyttää muissakin sovelluksissa.

Web-sovelluksen ymmärtämisessä tärkeitä kohtia ovat:
– ymmärtää, mitä generoidaan tai suoritetaan selaimessa, mitkä palvemilla
– huomioida, missä sovelluksen tila (sovelluksen datan säilys ja hallinta) on
– miten datan hallinta käyttöliittymän ja serverin välillä tapahtuu
– palvelinkutsujen ja niiden paluuarvojen hallinta
– arkkitehtuurimallien ymmärtäminen

Tunnetuimmat arkkitehtuurimallit lyhyesti:

(1) MVL (Model-View-Logic, nimetty tässä näin) on vanha rakenne, jossa logiikka on kapseloitu rajapinnan taakse. Tämä rajapintaolio on View-olion luokan jäsen. Vielä yksinkertaisempaa on, jos ei käytä rajapintaa. Tämä on edelleen toimiva rakenne, ja logiikka on täysin riippumaton käyttöliittymästä. Ongelmaa on tässä ainoastaan Viewissa, jossa joudutaan sijoittamaan data ”käsin” käyttöliittymään ja perinteisesti tässä käyttöliittymäkoodi pyrkii turpoamaan, ellei sitä kehitetä suunnitelmallisesti ja kurinalaisesti. Tämän erinomainen puoli on se, että tämä on aina toteutettavissa, tekniikasta riippumatta.

MVL architecture

(2) MVC (Model-View-Controller) on tavallaan yleisnimitys, jota voidaan käyttää, kun ei tarkemmin MV*-arkkitehtuuria määritellä. Tässä ideana on controllerin keskeisyys, se ottaa vastaan kutsut, valitsee ja alustaa viewin ja hakee datan modelilta, Esimerkiksi useimmat servlettia käyttävät Javan päälle tehdyt frameworkit ovat näitä ja tämän toiminta onkin helpoin ymmärtää servletti-sovelluksen kautta. Ongelmana on riippuvuuksien suuri määrä, joka tekee mallista sekavan näköisen, sekavamman kuin se on käytännössä. Tässä tyypillisesti kontrollerikoodi pyrkii paisumaan kohtuuttoman suureksi.

MVC architecture

(3) MVP (Model-View-Presenter) on Microsoftin kehittämä, ja siinä on ideana Presenterin keskeisyys. Käyttöliittymä pyritään pitämään mahdollisimman ohuena. Tässä erikoisuutena on rajapinta, jonka View toteuttaa. Hyvä puoli tässä on testattavuus, mikäli käyttöliittymä pystytään pitämään hyvin ohuena (ts. automaattitestauksen ulkopuolelle jää hyvin vähän sovelluksesta). Huono puoli on Presenterin riippuvuus em. rajapinnan määrityksestä. Rajapinnan toteutus kuitenkin erottaa täysin käyttöliittymän sovelluskoodista.

MVP architecture

(4) MVVM (Model-ViewModel-Model) perustuu databindaukseen. Databindaus voi olla sovellettuna muissakin malleissa, mutta tässä se on keskeinen. Käyttöliittymä on hyvin ohut tässä mallissa. Käyttöliittymän pitää huolehtia myös databindauksen määrittelystä. Hyviä puolia on selkeä alaspäin riippuvuus (kuten MVL:ssa), erittäin hyvä testattavuus (riippuvuuksien vähäisyys, käyttöliittymän ohuus). Huono puoli on sidonnaisuus tekniikkaan. Kaikkialla ei ole kaksisuuntaista databindausta tarjolla. Databindaus on hyvin toteutettu HTML-kirjastoissa (Angular, Knockout), joissa se on käyttöliittymässä ja huonosti esim. WPF:ssa tai JavaFX:ssa, joissa se on kontrollerissa.

MVVM architecture

Scroll to Top