Implementing Model-View Architecture in WPF technology

Full text

(1)ANTTI LEHTINEN MALLI-NÄKYMÄ-ARKKITEHTUURIN TEKNOLOGIALLA. SOVELTAMINEN. WPF-. Diplomityö. Tarkastaja: professori Kai Koskimies Tarkastaja ja aihe hyväksytty Tieto- ja sähkötekniikan tiedekuntaneuvoston kokouksessa 8. kesäkuuta 2011.

(2) ii. TIIVISTELMÄ TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan koulutusohjelma LEHTINEN, ANTTI: Malli-näkymä-arkkitehtuurin soveltaminen WPFteknologialla. Diplomityö, 76 sivua, 24 liitesivua Toukokuu 2012 Pääaine: Ohjelmistotuotanto Tarkastaja: professori Kai Koskimies Avainsanat: malli-näkymä-arkkitehtuuri, WPF, MVVM-suunnittelumalli Malli-näkymä-arkkitehtuurit tarjoavat työkaluja ja suunnitteluratkaisuja käyttöliittymäsovelluksien toteutukseen. Malli-näkymä-arkkitehtuurien tehtävänä on parantaa käyttöliittymäsovelluksien modulaarisuutta, toteutettavuutta, ylläpidettävyyttä sekä testattavuutta. Tärkein malli-näkymä-arkkitehtuureista saavutettava hyöty on näkymän erottaminen sovelluslogiikasta. Tunnetuimpia malli-näkymä-arkkitehtuureja ovat MVC ja MVP. Tässä työssä esitellään tunnetuimpien malli-näkymä-arkkitehtuurien rakenteet ja tehtävät. Työn alussa huomataan, että MVC- ja MVP-arkkitehtuurimallien käytännön soveltaminen on vaikeaa. Tämän diplomityön tarkoituksena on selvittää, kuinka kirjallisuudessa hyväksi todettu uusi malli-näkymä-arkkitehtuuri MVVM ja käyttöliittymäkirjasto WPF ratkaisevat todellisuudessa ongelmia, jotka liittyvät käyttöliittymäsovelluksien toteuttamiseen. Perehtyminen MVVM-suunnittelumallin mukaisen järjestelmän toteutukseen aloitetaan esimerkkisovelluksen avulla. Esimerkkisovellus havainnollistaa WPF-teknologian tärkeimmät ominaisuudet liittyen MVVM-suunnittelumallin toteutukseen. Esimerkkisovellus on toteutettu kirjallisuudessa esitettyjen ratkaisujen mukaisesti. Havaintoja ja kokemuksia MVVM-suunnittelumallin käytännön soveltamisesta saatiin Atostekin projektista. Projektissa toteutettiin asiakkaan vaatimia mittausjärjestelmä hyödyntämällä MVVM-suunnittelumallia ja WPF-teknologiaa. Projektissa saatuja havaintoja käsitellään tässä työssä. Projektissa sovellettua MVVM-suunnittelumallia arvioitiin modulaarisuuden, suorituskyvyn, uudelleenkäytettävyyden ja opittavuuden näkökulmista. Tässä työssä saatujen havaintojen perusteella MVVM-suunnittelumalli soveltuu hyvin käyttöliittymäsovelluksen arkkitehtuuriksi käytännön ohjelmistoprojektissa. MVVM-suunnittelumalli eroaa muista malli-näkymä-arkkitehtuureista, koska se tarjoaa myös matalan tason käytännön toteutusratkaisuja hyödyntäen WPF-teknologiaa. Kirjallisuudessa ja myös tässä työssä saatujen tuloksien perusteella MVVM-suunnittelumalli ja WPF-teknologia mahdollistavat nykyaikaisten ohjelmointityökalujen ja käyttöliittymäkirjastojen hyödyntämisen sekä tehokkaan tavan toteuttaa modulaarisia, uudelleenkäytettäviä, ylläpidettäviä ja opittavia käyttöliittymäsovelluksia..

(3) iii. ABSTRACT TAMPERE UNIVERSITY OF TECHNOLOGY Master’s Degree Programme in Information Technology LEHTINEN, ANTTI: Implementing Model-View Architecture in WPF technology Master of Science Thesis, 76 pages, 24 Appendix pages May 2012 Major: Software Engineering Examiner: Professor Kai Koskimies Keywords: model-view architecture, WPF, MVVM pattern Model-view architectures provide tools and design solutions for implementation of UI applications. Purpose of the model-view architecture is to improve modularity, feasibility, maintainability and testability of applications. Main achievement of the model-view architecture is to manage separation between data, behavior, and presentation. Two of the moset common model-view architectures today are MVC and MVP. This thesis presents structures and functions of these model-view architectures. This thesis begins by introducting a discovery that the MVC and the MVP architectures are difficult to apply in practice. Purpose of this thesis is to examine how a new model-view architecture MVVM and WPF technology solves the problems related to the implementation of UI applications in practice. Implementation of the MVVM pattern is presented through an example application. The example application demonstrates the most important features of the WPF technology related to the MVVM pattern. The example application is implemented with MVVM pattern concepts outlined in the literature. The MVVM pattern was applied in practice during Atostek’s software project. A measurement application for a customer was implemented by using the MVVM pattern and the WPF technology. Discoveries and experiences from the project are discussed in this thesis. MVVM pattern applied in the project was evaluated by modularity, performance, reusability and learnability points of view. An experience of this thesis shows that the MVVM pattern provides benefits when it is used to create architecture for a UI application. MVVM-pattern is different from other model-view architectures, because it offers low-level implementation solutions using WPF technology. In the literature and also in practice MVVM-pattern and WPFtechnology make it possible to use modern programming tools and user interface libraries to develope modular, reusable, maintainable and easily learned UI applications..

(4) iv. ALKUSANAT Tämän diplomityönaiheen on tarjonnut ja rahoittanut Atostek Oy. Haluan kiittää työn tarkastajaa professori Kai Koskimiestä ja työn ohjaajaa Miika Parviota. Kiittäisin myös Atostek Oy:n kaikkia työntekijöitä hyvän ja opettavaisen työympäristön tarjoamisesta. Erityiskiitokset isälle ja äidille kaikista neuvoista, joita olen elämäni aikana teiltä saanut. Teidän tuki ja kannustus on vienyt minua eteenpäin omalla opiskelu-urallani. Lopuksi lämmin kiitos avopuolisolleni Leenalle kaikesta tuesta jota olet minulle antanut.. Tampereella 15.4.2012. Antti Lehtinen.

(5) v. SISÄLLYS 1 2. 3. 4. Johdanto .................................................................................................................... 1 Malli-näkymä-arkkitehtuurit ..................................................................................... 3 2.1 Käsitteistö.......................................................................................................... 3 2.1.1 Malli-näkymä-arkkitehtuuri ................................................................. 3 2.1.2 Malli ..................................................................................................... 4 2.1.3 Näkymä ................................................................................................ 4 2.1.4 Arkkitehtuurimalli ............................................................................... 4 2.1.5 Arkkitehtuuri ........................................................................................ 4 2.1.6 Suunnittelumalli ................................................................................... 4 2.2 Malli-näkymä-arkkitehtuurien tehtävät ............................................................. 5 2.3 Malli-näkymä-arkkitehtuurien esittely .............................................................. 6 2.3.1 Arviointi ............................................................................................... 6 2.3.2 MVC – Model-View-Controller .......................................................... 6 2.3.3 MVP – Model-View-Presenter .......................................................... 10 2.3.4 MVVM – Model-View-ViewModel .................................................. 12 2.4 Malli-näkymä-arkkitehtuurien arviointi .......................................................... 15 MVVM-suunnittelumallin esimerkkitoteutus ......................................................... 16 3.1 Puhelinluettelosovellus ................................................................................... 16 3.2 Windows Presentation Foundation ................................................................. 18 3.2.1 XAML................................................................................................ 18 3.2.2 Looginen ja visuaalinen puu .............................................................. 21 3.2.3 Reititetyt tapahtumat .......................................................................... 22 3.2.4 Tiedon sitominen ............................................................................... 24 3.2.5 Tiedon validointi ................................................................................ 29 3.2.6 Tiedon esittäminen............................................................................. 31 3.2.7 Toiminnon suorittaminen................................................................... 33 3.3 Puhelinluettelosovelluksen toteutus MVVM-suunnittelumallilla ................... 37 3.3.1 Osien väliset riippuvuudet ................................................................. 37 3.3.2 AddressBookMainWindow-näkymä ................................................. 38 3.3.3 AddContactUserControl-näkymä ...................................................... 39 3.3.4 SearchContactUserControl-näkymä .................................................. 39 3.3.5 BaseViewModel-näkymämalli .......................................................... 41 3.3.6 SearchContactViewModel-näkymämalli ........................................... 41 3.3.7 ContactViewModel-näkymämalli ...................................................... 41 3.3.8 Mallin toteutus ................................................................................... 42 MVVM-suunnittelumallin soveltaminen ohjelmistoprojektissa ............................. 44 4.1 Toteutettava järjestelmä .................................................................................. 44 4.2 Järjestelmän arkkitehtuuri ............................................................................... 46 4.3 Näkymämallien luominen ............................................................................... 47 4.4 BaseViewModel-näkymämalli........................................................................ 49.

(6) vi 4.4.1 Näkymämallin päivittäminen............................................................. 49 4.4.2 Ikkunan sulkeminen näkymämallin avulla ........................................ 51 4.5 Virheilmoitukset.............................................................................................. 53 4.6 Toiminnon suorittaminen ja etenemispalkki ................................................... 55 4.7 Tiedon sidonta ja tyyppimuunnokset .............................................................. 58 4.8 Tiedon esittäminen taulukossa ........................................................................ 61 4.9 Mallin toteuttaminen ....................................................................................... 65 5 MVVM-suunnittelumallin arviointi ........................................................................ 67 5.1 Modulaarisuus ................................................................................................. 67 5.2 Suorituskyky ................................................................................................... 68 5.3 Näkymän uudelleenkäytettävyys .................................................................... 68 5.4 Näkymämallin uudelleenkäytettävyys ............................................................ 69 5.5 Uuden kokonaisuuden lisääminen .................................................................. 70 5.6 Opittavuus ....................................................................................................... 72 6 Yhteenveto .............................................................................................................. 73 Lähteet ............................................................................................................................. 75 Liite 1: AddressBookMainWindow-näkymä Liite 2: AddContactUserControl-näkymä Liite 3: SearchContactUserControl-näkymä Liite 4: BaseViewModel-näkymämalli Liite 5: SearchContactViewModel-näkymämalli Liite 6: ContactViewModel-näkymämalli Liite 7: Contact-luokka Liite 8: ModelManager-luokka Liite 9: XmlParser-luokka Liite 10: RelayCommand-luokka Liite 11: ViewModelFactory-luokka Liite 12: BaseViewModel-näkymämalli Liite 13: ProgressWindow-luokka Liite 14: Tyyppimuunnokset Liite 15: DataGrid-komponentti.

(7) 1. 1. JOHDANTO. Arkkitehtuurilla on suuri merkitys käyttöliittymäsovelluksien toteutuksessa. Arkkitehtuurin tarjoama modulaarisuus on tärkeää, jotta järjestelmän rakenne pysyy selkeänä. Selkeän rakenteen ja vastuunjaon ansiosta järjestelmän testaus, ylläpito ja uusien ominaisuuksien lisääminen helpottuu. Käyttöliittymäsovelluksissa arkkitehtuurin on mahdollistettava tiedon välitys käyttäjän ja tietomallin välillä. Ensimmäisistä käyttöliittymäsovelluksista alkaen malli-näkymä-arkkitehtuurit ovat tarjonneet työkaluja ja suunnitteluratkaisuja käyttöliittymäsovelluksien kehittäjille. Tunnetuin malli-näkymä-arkkitehtuuri on MVC (eng. Model-View-Controller). Vanhojen malli-näkymä-arkkitehtuurien ongelmana on, että niiden mukaisen käyttöliittymäsovelluksen toteuttaminen nykyaikaisilla ohjelmointiteknologioilla on mahdotonta. Tämän lisäksi korkean tason arkkitehtuurimallien ongelmana on arkkitehtuurimallin käytännön toteuttaminen. Korkean tason arkkitehtuurimallit ovat yleiskäyttöisiä ja teoriassa lupaavat ratkaista monia ongelmia liittyen järjestelmien toteuttamiseen. Kirjallisuudessa luvataan arkkitehtuurien parantavan modulaarisuutta, ylläpidettävyyttä, suorituskykyä, testattavuutta ja muutosten hallintaa. Arkkitehtuurimallien mahdollistamat hyödyt voidaan kuitenkin menettää epäonnistuneen toteutuksen seurauksena, koska korkean tason kuvaus ei tarjoa käytännön ratkaisuja toteuttajalle. Korkean tason arkkitehtuurimallin soveltamisesta saavutetut hyödyt riippuvat enemmän yksilön taidoista kuin käytettävästä arkkitehtuurimallista. Korkean tason arkkitehtuurimalleja soveltaville järjestelmille on tyypillistä, että järjestelmät eivät vastaa täysin alkuperäistä arkkitehtuurimallia, eivätkä ne ole keskenään yhdenmukaisesti toteutettuja. Tämä on seurausta siitä, että korkean tason arkkitehtuurimallien toteuttamiselle ei tarjota käytännön toteutusratkaisuja ja työkaluja siihen, kuinka arkkitehtuurimalli käytännössä toteutetaan niin, että sen hyödyt voidaan saavuttaa. Microsoftin Windows Forms-käyttöliittymäkirjasto on yleisesti käytössä ollut toteutusteknologia graafisten käyttöliittymäsovelluksien toteuttamiselle. Microsoft on jatkanut kehitystä ja julkaissut uuden käyttöliittymäkirjaston nimeltään Windows Presentation Foundation – WPF. WPF-teknologia tarjoaa nykyaikaisia menetelmiä ja työkaluja käyttöliittymäsovelluksien toteuttamiselle. Käyttöliittymäkirjaston lisäksi WPFteknologian kehityksessä on otettu huomioon toteutettavan järjestelmän arkkitehtuuriratkaisuja. WPF-teknologia on toteutettu tukemaan Microsoftin kehittämään MVVMsuunnittelumallia, joka on käyttöliittymäsovelluksiin toteutettava malli-näkymäarkkitehtuuri. MVVM eroaa muista korkean tason malli-näkymä-arkkitehtuureista siten, että se ottaa kantaa myös matalantason käytännön ratkaisuihin. Näin ollen MVVM tar-.

(8) 2 joaa järjestelmän kehittäjälle paremmat työkalut oikeaoppisen käyttöliittymäsovelluksen toteuttamiselle. Tämän diplomityön tarkoituksena on selvittää, kuinka kirjallisuudessa hyväksi todettu malli-näkymä-arkkitehtuuri MVVM ja käyttöliittymäkirjasto WPF ratkaisevat todellisuudessa ongelmia, jotka liittyvät käyttöliittymäsovelluksien toteuttamiseen. MVVM-suunnittelumallin toteutukseen WPF-teknologialla perehdytään esimerkkisovelluksen avulla. MVVM-suunnittelumallin sovellettavuutta ohjelmistoprojektiin arvioidaan perustuen kokemuksiin, joita saatiin hyödyntämällä MVVM-suunnittelumallia Atostekin projektissa. Projektin aikana saatuja havaintoja käydään läpi esittelemällä käyttöliittymäsovelluksen toiminnallisuuksia sovellettuna MVVM-suunnittelumallin mukaiseksi. Käsiteltäviä toiminnallisuuksia ovat näkymien päivittäminen, näkymien sulkeminen, tiedon esittäminen, virheilmoituksien esittäminen, etenemispalkin esittäminen ja mallin toteutus. MVVM-suunnittelumallin arvioinnissa keskitytään käyttöliittymäsovelluksen modulaarisuuden, suorituskyvyn, toteutettavuuden, ylläpidon ja opittavuuden parantamiseen. Luvussa 2 käsitellään malli-näkymä-arkkitehtuureja yleisesti. Luvussa käydään läpi yhteisiä ominaisuuksia ja hyötyjä joita voidaan saavuttaa hyödyntämällä malli-näkymäarkkitehtuureja. Luvussa esitellään kolme arkkitehtuuria MVC, MVP ja MVVM. Luvussa 3 perehdytään MVVM-suunnittelumallin toteuttamiseen WPF-teknologialla kirjallisuudessa esitettyjen teorioiden mukaisesti. Luvussa esitellään WPF-teknologian tärkeimmät ominaisuudet, jotka liittyvät MVVM-suunnittelumallin mukaisen sovelluksen toteuttamiseen. Lisäksi luvussa esitellään esimerkkisovellus, joka on toteutettu MVVM-suunnittelumallin mukaisesti. Luvussa 4 esitellään havaintoja, kuinka MVVMsuunnittelumallia voidaan soveltaa oikeassa ohjelmistoprojektissa. Luvussa esitellään toteutusratkaisuja, joita on tehty toteuttaessa MVVM-suunnittelumallin mukaista sovellusta ohjelmisto projektissa. Luvussa 5 arvioidaan, kuinka MVVM-suunnittelumallin soveltaminen projektissa onnistui. Suunnittelumallia arvioidaan modulaarisuuden, suorituskyvyn, toteutettavuuden, ylläpidon ja opittavuuden näkökulmista. Luvussa 6 esitellään yhteenveto tämän diplomityön tuloksista..

(9) 3. 2. MALLI-NÄKYMÄ-ARKKITEHTUURIT. Ohjelmistosuunnittelijoille käyttöliittymäsovelluksien suunnittelu ja toteuttaminen asettaa erityisiä haasteita. Sovelluslogiikan lisäksi ohjelmistosuunnittelijoiden tulee toteuttaa tiedon esittäminen käyttäjälle, sekä toteuttaa vuorovaikutus käyttäjän ja järjestelmän välille. Käyttöliittymäsovelluksien oletetaan tarjoavan visuaalisesti miellyttäviä käyttäjäkokemuksia, ja samalla tehokasta ja intuitiivista tietojen käsittelyä ja hallintaa ilman turhauttavia varmennuksia tai latausaikoja. Järjestelmän tulisi automatisoida itsestään selvät toiminnot, mutta silti antaa käyttäjälle vaikutelman siitä, että käyttäjä on tietoinen järjestelmän tilasta ja pystyy hallitsemaan järjestelmän tapahtumia. Jo ensimmäisistä käyttöliittymäsovelluksista alkaen malli-näkymä-arkkitehtuurit ovat tarjonneet ohjelmistosuunnittelijoille hyväksi todettuja käytäntöjä ja toteutustapoja käyttöliittymäsovelluksien toteutukseen (Reenskaug 2007). Tässä luvussa käsitellään malli-näkymä-arkkitehtuureihin liittyvää sanastoa ja termejä. Lisäksi perehdytään tunnetuimpiin malli-näkymä-arkkitehtuureihin, kuten MVC ja MVP, sekä havainnollistetaan, miksi malli-näkymä-arkkitehtuurit ovat merkittävässä asemassa käyttöliittymäsovelluksien kehityksessä. Luvun aikana huomataan, kuinka vanhoja malli-näkymä-arkkitehtuureja on vaikea toteuttaa tämän päivän ohjelmointiympäristöissä. Kappaleessa 2.3.4 esitellään uudenaikainen MVVM malli-näkymäarkkitehtuuri. Jokaisen esitetyn malli-näkymä-arkkitehtuurin jälkeen kyseistä arkkitehtuurimallia arvioidaan toteutettavuuden, yleiskäyttöisyyden, testattavuuden, opittavuuden ja ylläpidettävyyden näkökulmista. Arvioinnissa käytetään kolmetasoista asteikkoa +, ++ ja +++. Kappaleessa 2.4 malli-näkymä-arkkitehtuurien arvioinnit on koottu yhdeksi taulukoksi. Kirjallisuudessa luvataan (Anderson 2009; Smith 2009; Prism 2010; Garofalo 2011), että MVVM-suunnittelumalli mahdollistaa nykyaikaisten ohjelmointityökalujen ja käyttöliittymäkirjastojen hyödyntämisen sekä tehokkaan tavan toteuttaa visuaalisesti näyttäviä ja toiminnallisesti tehokkaita käyttöliittymäsovelluksia. Tämän työn seuraavissa luvuissa käsitellään MVVM-suunnittelumallin toteuttamista, soveltamista sekä syvällisempää arviointia sen todellisista hyödyistä.. 2.1. Käsitteistö. 2.1.1. Malli-näkymä-arkkitehtuuri. Tässä työssä malli-näkymä-arkkitehtuurilla tarkoitetaan yleistä käsitettä, joka kattaa kaikki arkkitehtuurit, joiden tarkoituksena on tarjota arkkitehtuuri- ja suunnitteluratkaisuja käyttöliittymäsovelluksien toteutukselle. Nimitys malli-näkymä syntyy siitä, että.

(10) 2. Malli-näkymä-arkkitehtuurit. 4. arkkitehtuurien toteutuksen ydin perustuu näkymän erottamiseen sovelluslogiikasta, eli järjestelmän jakaminen malliin ja näkymään. Useasti näissä arkkitehtuureissa on myös ohjaimen tapainen osa, jonka vastuulla on näkymän ja mallin yhdistäminen. Kappaleessa 2.2 on käsitelty malli-näkymä-arkkitehtuurien tyypillisiä tehtäviä ja tavoitteita. 2.1.2. Malli. Mallilla tarkoitetaan tässä työssä järjestelmän osaa, jonka tehtävänä on tietomallin toteuttaminen, tiedon varastointi ja tiedon käsittelyyn liittyvien toimintojen toteuttaminen. Hyvin suunniteltu malli on monikäyttöinen ja kuvaa jotain tiettyä asiakokonaisuutta todellisesta maailmasta. Mallin tehtävänä on kuvata todellisen maailman käsitteitä ja tarjota toiminnallisuutta, joiden avulla eri käsitteiden suhteita ja vaikutuksia toisiinsa voidaan mallintaa. 2.1.3. Näkymä. Näkymä on järjestelmän osa, jonka käyttäjä voi havaita. Järjestelmä koostuu useista näkymistä. Järjestelmän kaikkien näkymien muodostamaa yhteistä kokonaisuutta kutsutaan käyttöliittymäksi. Näkymän tehtävänä on tarjota käyttäjälle työkalut, joiden avulla järjestelmää voidaan hallita. Järjestelmän hallintaan liittyy tiedon hakemista, esittämistä, sekä erilaisten toimintojen suorittamista. 2.1.4. Arkkitehtuurimalli. Arkkitehtuurimallilla tarkoitetaan tässä työssä teoreettista kuvausta järjestelmän osista ja niiden välisistä vuorovaikutuksista. Arkkitehtuurimallissa kuvataan yleisesti eri osat, niiden vastuut ja tehtävät. Arkkitehtuurimalli on yleiskäyttöinen ja tarjoaa korkean tason suunnitteluratkaisuja, johonkin tiettyyn ongelmaan. Arkkitehtuurimallin hyödyntäminen tarkoittaa, että arkkitehtuurimallissa kuvattuja asioita sovelletaan omaan ongelmaan. Arkkitehtuurimalli ei ota kantaa toteutusteknologiaan. 2.1.5. Arkkitehtuuri. Arkkitehtuuri on kuvaus toteutetun järjestelmän suunnitteluratkaisuista, komponenteista ja niiden välisistä vuorovaikutuksista sekä vastuista (Bass et al. 2003). Arkkitehtuurilla tarkoitetaan tässä työssä kuvausta toteutetusta arkkitehtuurimallista. Arkkitehtuuri on näin ollen tarkempi kuvaus siitä, kuinka jokin arkkitehtuurimalli on toteutettu jossain tietyssä järjestelmässä. 2.1.6. Suunnittelumalli. Suunnittelumalli (eng. design pattern) on matalan tason toteutusratkaisu. Suunnittelumalli kuvaa käytännössä, kuinka jokin ongelma ratkaistaan. Yleensä suunnittelumallit ovat tunnettuja ja käytännössä hyväksi havaittuja menetelmiä ja ratkaisuja, joilla tietty ongelma voidaan ratkaista tietyssä tilanteessa. Suunnittelumalli ei välttämättä ole sidok-.

(11) 2. Malli-näkymä-arkkitehtuurit. 5. sissa johonkin tiettyyn teknologiaan, mutta on silti tarkka kuvaus toteutuksesta. (Gamma et al. 1994.). 2.2. Malli-näkymä-arkkitehtuurien tehtävät. Malli-näkymä-arkkitehtuurien tehtävänä on parantaa käyttöliittymäsovelluksien modulaarisuutta, toteutettavuutta, ylläpidettävyyttä sekä testattavuutta. Malli-näkymäarkkitehtuurit tarjoavat ohjelmistosuunnittelijoille työkaluja, joiden avulla voidaan toteuttaa tehokkaita ja ylläpidettäviä käyttöliittymäsovelluksia. Käyttöliittymäsovelluksen toteutuksessa on helppo päätyä ratkaisuun, jossa järjestelmän sovelluslogiikkaa toteutetaan jonkin tietyn näkymän yhteyteen. Ratkaisu on helppo, ja se on vaivaton toteuttaa. Samaa toiminnallisuutta ja tietosisältöä voi kuitenkin tarvita jokin toinen järjestelmän osa tai näkymä. Tästä seuraa, että viitteitä tietosisältöön on ympäri järjestelmää, ja lopulta mikään osa järjestelmästä ei ole täysin vastuussa tiedon hallinnasta. Kun tietosisällön rakenteeseen tai sen käsittelyyn tulee muutos, muutoksen aiheuttamat korjaukset pitää toteuttaa kaikkialle järjestelmään. Malli-näkymäarkkitehtuurien yhteinen tehtävä on erottaa järjestelmän sovelluslogiikka sen käyttöliittymästä. Vastuualueiden jakaminen eri osille ja modulaarisuus on tärkeää, jotta tunnistetaan mihin osaan järjestelmästä tietyt toiminnallisuudet tai muutokset tulisi kohdistaa. Arkkitehtuurin merkitys kasvaa järjestelmän suuruuden kasvaessa. Pienissä järjestelmissä muutokset ja ylläpitotoimet on helppo hallita, mutta suurissa järjestelmissä muutosten hallinta on vaikeampaa ja muutosten toteuttaminen vie enemmän aikaa. Järjestelmän testaaminen käyttöliittymän välityksellä vaatii usein testaajan toimenpiteitä. Mikäli sovelluslogiikkaa on toteutettu käyttöliittymän yhteyteen, on suuri osa järjestelmän testauksesta suoritettava käyttöliittymän välityksellä. Käyttöliittymätestauksen automatisointi on työlästä, koska käyttöliittymään kohdistuu usein visuaalisia muutoksia jolloin painikkeiden sijainnit muuttuvat. Muutoksien seurauksena myös testitapaukset tulee päivittää. Malli-näkymä-arkkitehtuurin ansiosta mallin toteuttama sovelluslogiikka on itsenäinen kokonaisuus, joka tarjoaa palveluita näkymille. Mallin tarjoamiin palveluihin voidaan toteuttaa automaattisesti ajettavia yksikkötestejä, jotka testaavat samat palvelut mitä näkymät käyttävät. Mallin rajapinta on staattisempi kuin järjestelmän käyttöliittymä, jolloin testitapauksia ei tarvitse päivittää niin useasti. Mallinäkymä-arkkitehtuurin mahdollistama testauksen automatisointi säästää aikaa ja resursseja. Malli-näkymä-arkkitehtuurin ansiosta muutokset käyttöliittymään ja uusien näkymien tekeminen järjestelmään on helpompaa, koska käyttöliittymä ei sisällä sovelluslogiikkaa. Uusi näkymä voidaan toteuttaa esittämään tietomallista jotain uutta tietoa. Hyvin toteutetun arkkitehtuurin ansioista järjestelmään tehtävät korjaukset ja muutokset voidaan rajata selkeisiin kokonaisuuksiin, jolloin järjestelmän ylläpidettävyys paranee. (Buschmann et al. 1996; Potel 1996; Smith 2009; Garofalo 2011.).

(12) 2. Malli-näkymä-arkkitehtuurit. 2.3. Malli-näkymä-arkkitehtuurien esittely. 2.3.1. Arviointi. 6. Kappaleessa 2.3 esitellään tunnetuimmat malli-näkymä-arkkitehtuurit. Kappaleessa esitettyjä malli-näkymä-arkkitehtuureja arvioidaan niiden ominaisuuksien perusteella. Seuraavassa listassa on esiteltynä arvioinnissa käytettävät ominaisuudet ja niiden kuvaukset. • Toteutettavuus: Kuinka helppo arkkitehtuurimalli on käytännössä toteuttaa? Onko arkkitehtuurimallin toteuttamiseen työkaluja tai ohjeita? Vastaako teoreettinen kuvaus arkkitehtuurimallista käytännön todellisuutta? • Yleiskäyttöisyys: Voidaanko arkkitehtuurimallia soveltaa eri ongelmiin? Voiko arkkitehtuurimallin toteuttaa eri teknologioilla? • Testattavuus: Tarjoaako arkkitehtuurimalli lisäetua järjestelmän testaukselle? Mahdollistaako arkkitehtuurimalli automatisoidun testauksen? • Opittavuus: Kuinka helposti arkkitehtuurimallin ydinajatuksen voi oppia? Kuinka helposti toteutettu arkkitehtuuri voidaan oppia ja ymmärtää? Onko kirjallisuudessa saatavilla tietoa arkkitehtuurimallin toteuttamisesta? • Ylläpidettävyys: Kuinka helppo arkkitehtuurimallin mukaiseen järjestelmään on tehdä muutoksia? Mahdollistaako arkkitehtuurimalli uusien osien lisäämisen jälkikäteen? Malli-näkymä-arkkitehtuurien arviointi toteutettiin arvioimalla jokaisen arkkitehtuurimallin ominaisuuksia asteikolla +, ++ ja +++. Arkkitehtuurimalleja arvioitiin kirjallisuudesta saatavan tiedon ja käytännön kokemuksien perusteella. Jokaisen arkkitehtuurimallin esittelyn jälkeen arkkitehtuuria arvioitiin itsenäisesti. Arvioinnin tulokset ja johtopäätökset on koottu yhteen kappaleessa 2.4. 2.3.2. MVC – Model-View-Controller. Malli-Näkymä-Ohjain (eng. MVC – Model View Controller) on ensimmäinen arkkitehtuurimalli, jonka tarkoitus on erottaa järjestelmän sovelluslogiikka käyttöliittymästä. Mallin on kehittänyt Trygve Reenskaug vuonna 1979 (Reenskaug 2011). MVCarkkitehtuurimalli rakentuu kuvan 1 mukaisesti kolmesta osasta. Malli (Model) on esitys järjestelmän tietosisällöstä sekä sitä käsittelevästä sovelluslogiikasta. Näkymä (View) on esitystapa, jolla tietosisältö näytetään käyttäjälle. Ohjain (Controller) vastaa käyttäjän syötteiden hallinnasta. (Reenskaug 2007.).

(13) 2. Malli-näkymä-arkkitehtuurit. 7. Kuva 1. MVC-arkkitehtuurimalli (Interactive Application Architecture Patterns 2007). MVC-arkkitehtuurimallissa malli on itsenäinen kokonaisuus, joka toteuttaa järjestelmän toiminnallisuuden tiedon käsittelylle ja varastoinnille. Mallin toteutuksessa ei oteta kantaa siihen, miten tieto esitetään käyttäjälle. Järjestelmään kuuluu aina yksi malli, jota näkymät ja ohjaimet hyödyntävät. Mallin toteutuksessa ei olla kiinnostuneita siitä, mitkä osat mallia käyttävät, vaan mallista tulisi toteuttaa järjestelmän yleiskäyttöinen tietosisältö. Tämä suunnitteluratkaisu mahdollistaa sovelluslogiikan erottamisen muusta järjestelmästä. (Buschmann et al. 1996; Reenskaug 2007.) Malliin tulisi toteuttaa järjestelmän toiminnallisuutta, joka käsittelee järjestelmän tietoa ja laskentaa. Funktionaalinen toiminnallisuus, joka liittyy tiedon esittämiseen käyttäjälle, on ohjaimen tehtävä. Tästä seuraa, että sovelluslogiikka jakautuu kahteen eri kokonaisuuteen, tiedonkäsittelyyn ja tiedon esittämiseen. Tiedon käsittely on mallin tehtävä, ja tiedon esittäminen on ohjaimen ja näkymien tehtävä. Näkymät ja ohjaimet muodostavat järjestelmän käyttöliittymän, ja toteuttavat tiedon esittämisen käyttäjälle. MVC-arkkitehtuurimallin mukaisesti näkymään kuuluu aina yksi ohjain, mutta ohjain voi ohjata useampaa näkymää. Ohjaimen tehtävänä on toimia välikappaleena käyttäjän ja järjestelmän välillä. Ohjain käsittelee kaikki järjestelmään syötteet, esimerkiksi hiiren ja näppäimistön painallukset. Ohjain tulkitsee käyttäjän syötteet, ja kutsuu näkymää ja mallia syötteitä vastaavilla toiminnallisuuksilla. Näkymän tehtävänä on esittää käyttäjälle järjestelmän tila. (Buschmann et al. 1996; Reenskaug 2007.) Tiedonvälitys järjestelmän tietomallin ja käyttöliittymän välillä voidaan toteuttaa passiivisena tai aktiivisena. Passiivisessa toteutuksessa ohjaimen vastuulla on ilmoittaa näkymille, milloin järjestelmän tietosisältö on muuttunut, jolloin näkymät käyvät päivittämässä oman tietonsa mallista. Aktiivisessa toteutuksessa näkymät ovat sidottuina kuuntelemaan mallissa tapahtuvia muutoksia. (Garofalo 2011) Aktiivisen toteutuksen näkymien ja mallin välinen vuorovaikutus voidaan toteuttaa muun muassa tarkkailijasuunnittelumallin avulla (Fowler 2006). Tarkkailija-suunnittelumallin (eng. Observer pattern) mukaisesti näkymät voidaan asettaa mallin kuuntelijoiksi. Kun jonkin toiminnon seurauksena mallin tietosisältö muuttuu, se ilmoittaa muutoksesta näkymille. Nä-.

(14) 2. Malli-näkymä-arkkitehtuurit. 8. kymät vastaanottavat tiedon mallin muutoksesta ja osaavat päivittää itsensä hakemalla uudet tiedot mallista. (Gamma et al. 1994, s. 293.) MVC-arkkitehtuurimallin mukainen käyttäjän syötteiden eteneminen on esitetty kuvassa 2.. Kuva 2. Käyttäjän syötteiden eteneminen MVC-arkkitehtuurimallissa. 1. 2. 3. 4. 5.. Käyttäjä antaa järjestelmälle syötteen, jolla hän haluaa tietyn tuotteen tiedot. Ohjain tulkitsee syötteen ja pyytää mallia hakemaan tuotteen tiedot. Ohjain ilmoittaa näkymälle, että uudet tiedot voidaan päivittää. Näkymä päivittää oman tietosisällön hakemalla tiedot mallista. Käyttäjä saa syötteelleen vastauksen havainnoimalla näkymää.. Reenskaugin kuvaama MVC-arkkitehtuurimallin perimmäinen tarkoitus on luoda yhteys käyttäjien kuvitteellisen mallin ja tietojärjestelmän tietomallin välille. Mallien välillä toimii ohjaimesta ja näkymistä koostuva työkalu (eng. Tool). Työkalu edustaa jotain tiettyä näkemystä mallista ja antaa käyttäjälle mahdollisuuden hallita tietojärjestelmän tietomallia. Käyttäjä ei käytä tietojärjestelmän tietomallia suoraan vaan hyödyntää sen palveluita työkalun välityksellä, ks. kuva 3. Yhteen tietomalliin voi liittyä samanaikaisesti useita erilaisia työkaluja, eli käyttäjiä. Arkkitehtuurin ansiosta on mahdollista, että samanaikaisesti useampi käyttäjä saa vaikutuksen siitä, että käyttää samaa tietomallia suoraan vaikka todellisuudessa tietomallia käytetään erillisen työkalun välityksellä. Reenskaugin kuvaaman työkalun avulla voidaan toteuttaa järjestelmiä jotka hyödyntävät samaa tietomallia ja mahdollistavat tuen usealle käyttäjälle samanaikaisesti. (Reenskaug 2011.).

(15) 2. Malli-näkymä-arkkitehtuurit. 9. Kuva 3. MVC-arkkitehtuurimallin olennainen tarkoitus (Reenskaug 2011). Reensgaugin MVC-arkkitehtuurimallilla on merkittävä asema malli-näkymäarkkitehtuurien historiassa. Se on ensimmäinen arkkitehtuurimalli, joka tarjoaa ratkaisun näkymän ja sovelluslogiikan erottamiseen toisistaan. MVC-arkkitehtuurimalli on toiminut arkkitehtuurina ensimmäisien käyttöliittymien ja käyttöliittymäkirjastojen toteutuksessa Smalltalk-kielellä (Reenskaug 2011). MVC-arkkitehtuurimalli on kuvattu hyvin korkealla tasolla, joka tekee siitä yleiskäyttöisen. Yleiskäyttöinen kuvaus arkkitehtuurimallista antaa mahdollisuuden soveltaa ratkaisua moneen eri tilanteeseen. Tämä on aiheuttanut sen, että MVC-arkkitehtuurimallista on olemassa monta erilaista toteutusta. Osa väitetyistä MVC-arkkitehtuurimallin toteutuksista vastaa lopulta hyvin vähän alkuperäistä arkkitehtuurimallia. Ohjelmointiympäristöt ja käyttöliittymien ohjelmointi on kehittynyt merkittävästi vuodesta 1979, jolloin MVC-arkkitehtuurimalli on julkaistu. Käyttäjän syötteiden hallinta ohjaimen avulla on suurin ongelma MVC-arkkitehtuurimallin mukaisen järjestelmän toteuttamisessa tänä päivänä. Ohjelmointiympäristöt sisältävät valmiita käyttöliittymäkomponentteja, jotka toteuttavat syötteiden vastaanottamisen ja hallinnan. Tämä tekninen ratkaisu aiheuttaa sen, että käyttäjän syötteiden hallinta on toteutettava näkymässä. Tästä seuraa, että MVC-arkkitehtuurimallin yksityiskohtainen toteuttaminen koko järjestelmän arkkitehtuurina tämän päivän ohjelmointiympäristöissä on mahdotonta. MVC-arkkitehtuurimalli on tarjonnut ja tarjoaa edelleen hyvän teorian siitä, kuinka käyttöliittymäsovelluksien tarkoitus on luoda yhteys käyttäjien kuvitteellisen tietomallin ja sovelluksen tietojärjestelmän tietomallin välille. Tietomallien yhdistäminen on yhteinen tavoite kaikille malli-näkymä-arkkitehtuureille. MVC-arkkitehtuuri on toiminut pohjana monelle uudelle malli-näkymä-arkkitehtuurille. Yksi uudempi malli-näkymäarkkitehtuuri on MVP, joka on kuvattu seuraavassa kappaleessa. Seuraavassa listassa on arvioitu MVC-arkkitehtuurimallia • Toteutettavuus (+): Alkuperäisen MVC-arkkitehtuurimallin toteuttaminen tämän päivän ohjelmointiympäristössä on mahdotonta, koska ohjelmointiympäristöjen käyttöliittymäkomponentit toteuttavat käyttäjän syötteiden hallinnan. MVC-arkkitehtuurimallia kuvaava kirjallisuus esittelee arkkitehtuurimallin kor-.

(16) 2. Malli-näkymä-arkkitehtuurit. •. •. •. •. 2.3.3. 10. kealla tasolla. Toteuttajalla on suuri vastuu toteutuksen onnistumisesta, koska arkkitehtuurin kuvaus voidaan ymmärtää monella tavalla. Yleiskäyttöisyys (+++): MVC-arkkitehtuurimalli on yleiskäyttöinen arkkitehtuuri. Arkkitehtuurimallin teoriaa voidaan hyödyntää monella eri tavalla moneen eri ongelmaan. Testattavuus (++): MVC-arkkitehtuurimalli jakaa järjestelmän kolmeen eri kokonaisuuteen. Jokaista eri osaa voidaan testata omina kokonaisuuksinaan. Arkkitehtuurimalli ei kuitenkaan tarjoa selkeää rajapintaa toiminnallisuuteen. Järjestelmän toiminnallisuuden muodostaa näkymän ja ohjaimen muodostamat parit. Opittavuus (+): MVC-arkkitehtuurimallin kuvaukset ovat korkealla tasolla, jolloin arkkitehtuurimallin voi ymmärtää monella eri tavalla. MVCarkkitehtuurimallin mukaiset järjestelmät eivät välttämättä ole rakenteeltaan yhdenmukaisia. Ylläpidettävyys (+): Uusien näkymien lisääminen vaatii myös uusien ohjaimien toteuttamista. MVP – Model-View-Presenter. Malli-Näkymä-Esittäjä (eng. MVP – Model View Presenter) on IBM:n kehittämä malli-näkymä-arkkitehtuuri. MVP tarjoaa yleiskäyttöisen arkkitehtuurimallin käyttöliittymäkomponenttien sekä käyttöliittymäsovelluksien kehitykseen. Ensimmäinen julkaisu on Mike Potelilta vuodelta 1996, jolloin MVP-arkkitehtuurimalli kehitettiin C++ ja Java ohjelmointikielille. MVP perustuu MVC-arkkitehtuurimalliin, ja siinä on paljon samoja piirteitä kuin vanhemmassa MVC-arkkitehtuurimallissa. Suurin ero on käyttäjän syötteiden käsittelyssä. MVP-arkkitehtuurimallissa näkymä vastaa käyttäjän syötteiden vastaanottamisesta. (Potel 1996.) MVP-arkkitehtuurimalli on esitetty kuvassa 4.. Kuva 4. MVP-arkkitehtuurimalli (Potel 1996)..

(17) 2. Malli-näkymä-arkkitehtuurit. 11. MVP-arkkitehtuurimallissa näkymä (View) seuraa käyttäjän tekemiä toimintoja ja hallitsee niistä aiheutuvia tapahtumia. Näkymä ei toteuta logiikkaa toimintojen suorittamiseksi vaan kutsuu esittäjään (Presenter) toteutettuja toiminnallisuuksia. Esittäjä sisältää tarvittavan logiikan toiminnallisuuden suorittamiselle ja tekee tarvittavat muutokset malliin (Model). Malli tarjoaa toiminnallisuuden tiedon varastoinnille ja käsittelylle. Rakenteen ansiosta sovelluslogiikka ei ole sidoksissa näkymään. Esittäjään toteutettuja toiminnallisuuksia voidaan kutsua erilaisista käyttöliittymistä tai suoraan jonkin toisen ohjelman toimesta. Mallissa tapahtuvat muutokset välitetään tarkkailijasuunnittelumallin avulla näkymään. (Potel 1996.) MVP-arkkitehtuurimallin tärkein periaate on jakaa järjestelmän vastuu käyttöliittymän ja tiedonhallinnan osa-alueisiin. Käyttöliittymän osa-alue on esittäjän ja näkymän vastuulla. Osa-alueen tehtävänä on vastata kysymykseen: Kuinka käyttäjä on vuorovaikutuksessa järjestelmän tiedon kanssa? Käyttöliittymän toteutuksessa on tärkeää tiedon esittäminen näkymässä ja käyttäjän syötteiden liittäminen sovelluslogiikan toimintoihin. Tiedonhallinnan osa-alue on esittäjän ja mallin vastuulla. Osa-alueen tehtävänä on vastata kysymykseen: Kuinka järjestelmän tietoa käsitellään? Tiedonhallinta koostuu käytettävissä olevan tiedon määrittämisestä, valitsemisesta sekä muutoksien tekemisestä. (Potel 1996.) MVP-arkkitehtuurimallin toteutus nykyisillä ohjelmointikielillä ja -ympäristöillä on suoraviivaisempaa kuin MVC-arkkitehtuurimallin toteutus. MVP-arkkitehtuurimalli tukee kehitystä, jossa näkymän käyttöliittymäkomponentit toteuttavat käyttäjän syötteiden hallinnan. Toinen merkittävä etu MVP-arkkitehtuurimallissa on esittäjän toteuttama rajapinta, joka kapseloi järjestelmän sovelluslogiikan. Esittäjän avulla sovelluslogiikka ja tiedonhallinta on rajattu selkeäksi kokonaisuudeksi. Esittäjän tarjoamaa toiminnallisuutta on helppo hyödyntää uusista näkymistä tai kokonaan eri järjestelmien osista. MVP-arkkitehtuurimallin mukaisen järjestelmän testaus voidaan automatisoida kirjoittamalla testitapauksia, jotka testaavat esittäjän toiminnallisuuksia. Suuri osa järjestelmätestauksesta voidaan kattaa automaattisilla testitapauksilla, koska näkymät ja muut järjestelmän osat hyödyntävät näitä samoja toiminnallisuuksia. (Potel 1996; Fowler 2006.) Seuraavassa listassa on arvioitu MVP-arkkitehtuurimallia • Toteutettavuus (++): MVP-arkkitehtuurimalli voidaan toteuttaa tämän päivän ohjelmointiympäristöillä. Arkkitehtuurimallin kuvaukset ovat kuitenkin korkealla tasolle esitettyjä, joten toteuttajan tulee ratkaista tekniset yksityiskohdat. • Yleiskäyttöisyys (++): MVP-arkkitehtuurimallin yleiskäyttöisyys on rajoittuneempi kuin MVC-arkkitehtuurimallin. • Testattavuus (+++): MVP-arkkitehtuurimallin esittäjä toteuttaa rajapinnan, jonka avulla järjestelmän sovelluslogiikkaa voidaan testata. • Opittavuus (+): MVP-arkkitehtuurimallin kuvaukset ovat korkealla tasolla, jolloin arkkitehtuurimallin voi ymmärtää monella eri tavalla. MVParkkitehtuurimallin mukaiset järjestelmät eivät välttämättä ole rakenteeltaan yhdenmukaisia..

(18) 2. Malli-näkymä-arkkitehtuurit •. 2.3.4. 12. Ylläpidettävyys (++): MVP-arkkitehtuurimallin esittäjä kapseloi järjestelmän sovelluslogiikan, joten järjestelmään tehtävien muutoksien seuraukset voidaan rajata tiettyyn osaan järjestelmästä.. MVVM – Model-View-ViewModel. Malli-Näkymä-Näkymämalli (eng. MVVM – Model View ViewModel) on tässä luvussa käsiteltävistä malli-näkymä-arkkitehtuureista uusin. MVVM on eniten teknologia riippuvainen arkkitehtuuri ja eroaa näin ollen edellä esitetyistä muista korkean tason malli-näkymä-arkkitehtuureista. MVVM ottaa kantaa niin matalan tason toteutusratkaisuihin, kuin myös korkean tason arkkitehtuuri rakenteeseen. Kirjallisuudessa, ja myös tässä työssä, MVVM malli-näkymä-arkkitehtuuria kutsutaan MVVMsuunnittelumalliksi (eng. MVVM design pattern). (Smith 2009; Garofalo 2011.) MVVM-suunnittelumallin on kehittänyt Microsoft, ja se on peräisin MVParkkitehtuurimallista. Microsoftin uusi WPF-käyttöliittymäkirjasto on suunniteltu ja toteutettu niin, että WPF-teknologian kaikki ominaisuudet saadaan tehokkaasti hyödynnettyä käyttämällä MVVM-suunnittelumallia. Suunnittelumallia voidaan soveltaa myös muihin toteutusteknologioihin, mutta WPF-teknoligian tapa määritellä käyttöliittymän XAML-kuvauskielellä on avainasemassa toteutettaessa MVVM-suunnittelumallin mukaista järjestelmää. MVVM-suunnittelumallin toteutusta ja soveltamista jatketaan tämän työn seuraavissa luvuissa. Tässä luvussa keskitytään suunnittelumallin yleiseen rakenteeseen. (Smith 2009; Garofalo 2011.) MVVM-suunnittelumalli muodostuu kuvan 5 mukaisesti näkymästä (View), näkymämallista (ViewModel) sekä mallista (Model).. Kuva 5: MVVM-suunnittelumalli (Prism 2010, s. 53). Malli kuvaa järjestelmän tietomallia. Mallin tehtävänä on varastoida järjestelmän tieto ja mahdollistaa sen käyttö. Näkymä muodostaa järjestelmän käyttöliittymän ja tarjoaa käyttäjälle mahdollisuuden havainnoida järjestelmän tietoa ja suorittaa toimenpiteitä. Näkymämalli yhdistää järjestelmän mallin ja näkymän. Sen tehtävänä on toteuttaa käyttäjälle tarjotut toiminnallisuudet ja huolehtia malliin kohdistuvista muutoksista. Näkymämalli kapseloi järjestelmän sovelluslogiikan ja tarjoaa näkymille rajapinnan toimintojen suorittamiselle ja tiedon esittämiselle. (Prism 2010; Garofalo 2011, ss. 3943.).

(19) 2. Malli-näkymä-arkkitehtuurit. 13. MVVM hyödyntää Fowlerin (2004) esittelemää PM-suunnittelumallia (eng. PM – Presentation Model). PM-suunnittelumallin ydin on erottaa näkymien toteutus visuaaliseen toteutukseen sekä toiminnalliseen käyttäytymiseen (Fowler 2004). MVVM suunnittelumallissa näkymä toteuttaa käyttöliittymien visuaalisen ulkonäön. Näkymän tehtävänä on määritellä, minkälaisista komponenteista näkymä muodostuu ja mitä toimintoja näkymässä on mahdollista suorittaa. Näkymämallin tehtävänä on tarjota rajapinta järjestelmän tietomalliin ja toiminnallisuuteen, joihin näkymä tai näkymät voivat sitoutua. MVVM-suunnittelumallissa näkymämallit hallitsevat myös näkymien tilatietoa ja tarjoavat näkymille tiedon, milloin tietyt toiminnot ovat käytettävissä. (Smith 2009; Garofalo 2011). MVVM-suunnittelumallin osat muodostavat kuvan 6 mukaisen kerrosarkkitehtuurin.. Kuva 6: Osien väliset suhteet MVVM-suunnittelumallissa (Anderson 2009). MVVM-suunnittelumalli perustuu siihen, että eri osat tunnistavat vain kuvassa 6 alempana olevia osia. Malli tarjoaa yleiskäyttöisen kuvauksen järjestelmän tietomallista, mutta ei tiedä, mitkä osat tai järjestelmät sitä käyttävät. Näkymämalli kapseloi mallin ja toteuttaa lisää tarvittavaa toiminnallisuutta ja sovelluslogiikkaa. Näkymämalli tuntee mallin, jonka avulla toteuttaa toiminnallisuutta, mutta näkymämalli ei tiedä, kuka sen toteuttamia palveluita hyödyntää. Kerrosarkkitehtuurijaon ansiosta MVVMsuunnittelumallin mukaiselle järjestelmälle voidaan toteuttaa uusia näkymiä helposti, koska näkymät hyödyntävät vain näkymämallien tarjoamia palveluita. (Anderson 2009, ss. 373-402.) MVVM-suunnittelumallin muodostama modulaarisuus on merkittävä hyöty, joka saavutetaan hyödyntämällä suunnittelumallia. Selkeän rakenteen ansiosta järjestelmästä saadaan ylläpidettävä ja muutoksien tekeminen helpottuu. MVVM-suunnittelumallin mukaisesti näkymä on näkymämallin tarkkailija, joka mahdollistaa uusien näkymien toteuttamisen ja vanhojen muokkaamisen ilman muutoksia sovelluslogiikkaan tai tietomalliin. Suunnittelumalli mahdollistaa myös näkymämallien uudelleenkäytettävyyden. (Anderson 2009; Smith 2009; Garofalo 2011.) WPF-teknologia ja XAML-kuvauskieli mahdollistavat tehokkaan ja helppokäyttöisen tavan toteuttaa MVVM-suunnittelumallin mukaisen järjestelmän. WPF-teknologian tarjoamat uudet ominaisuudet tukevat MVVM-suunnittelumallin periaatteita. WPF-.

(20) 2. Malli-näkymä-arkkitehtuurit. 14. teknologian avulla MVVM-suunnittelumalli on helposti toteutettavissa. WPFteknologian ansiosta MVVM-suunnittelumallin edut ovat mahdollista saavuttaa myös käytännössä. (Anderson 2009; Smith 2009; Garofalo 2011.) Malli-näkymä-arkkitehtuurien ongelma on niiden tulkitseminen. Jokainen toteuttaja tulkitsee arkkitehtuurit omalla tavallaan, johtuen osaksi siitä, että arkkitehtuureja on vaikea dokumentoida. Arkkitehtuurit antavat yleensä vain teoreettisen kuvan järjestelmän rakenteesta, jolloin käytännön toteutusratkaisut ovat täysin toteuttajan vastuulla. Tärkeää on, että arkkitehtuurien perimmäinen tarkoitus säilytetään toteutuksessa. MVC ja MVP malli-näkymä-arkkitehtuurit on kuvattu korkealla tasolla, ja ne eivät ota kantaa yksityiskohtaisiin toteutusratkaisuihin. MVVM-suunnittelumalli poikkeaa näistä mallinäkymä-arkkitehtuureista. MVVM-suunnittelumalli on kehitetty toteutettavaksi WPFteknologialla, ja se tarjoaa myös matalan tason toteutusratkaisuja oikeaoppisen MVVMsuunnittelumallin toteutukselle. (Smith 2009; Prism 2010.) Seuraavassa listassa on arvioitu MVVM-suunnittelumallia • Toteutettavuus (+++): MVVM-suunnittelumallin mukaisen järjestelmän toteuttamiseen on saatavilla tarkat ohjeet. WPF-teknologia toteuttaa monia teknisiä työkaluja, joiden avulla MVVM-suunnittelumallin hyödyt voidaan käytännössä saavuttaa. • Yleiskäyttöisyys (++): MVVM-suunnittelumalli on tarkoitettu toteutettavaksi WPF-teknologialla. Suunnittelumallin toteuttaminen jollakin muulla ohjelmointikielellä lisää toteutettavien yksityiskohtien määrää. • Testattavuus (+++): MVVM-suunnittelumalli jakaa järjestelmän selkeisiin kokonaisuuksiin joita voidaan testata. Näkymämallit toteuttavat järjestelmän sovelluslogiikan ja näkymien tilatietoa, joten järjestelmän toiminnallisuuteen voidaan toteuttaa automaattisia testitapauksia. • Opittavuus (++): MVVM-suunnittelumallin mukaisen järjestelmä toteuttamiseen löytyy hyvin ohjeita. MVVM-suunnittelumallin mukaiset järjestelmät toteuttavat saman rakenteen, jolloin toteutetun järjestelmän rakenne on helppo oppia ja ymmärtää. • Ylläpidettävyys (+++): MVVM-suunnittelumallissa näkymät ovat tapa esittää tietoa näkymämalleista, joten uusien näkymien luominen järjestelmään on helppoa. Näkymämalleja voidaan uudelleenkäyttää esittämällä samaa tietoa järjestelmän toisessa näkymässä..

(21) 2. Malli-näkymä-arkkitehtuurit. 2.4. 15. Malli-näkymä-arkkitehtuurien arviointi. Taulukon 1 perusteella MVVM-suunnittelumalli on soveltuvin vaihtoehto mallinäkymä-arkkitehtuuriksi. MVP ja MVVM ovat rakenteeltaan samantapaisia, mutta MVVM-suunnittelumallin toteutettavuus ja ylläpidettävyys ovat parempia. MVVMsuunnittelumalli kokoaa yhteen vanhojen malli-näkymä-arkkitehtuurien hyviä puolia ja tarjoaa hyvät työkalut arkkitehtuurimallin toteuttamiseen. MVVM-suunnittelumallin hyvä toteutettavuus mahdollistaa malli-näkymä-arkkitehtuurista saatavien hyötyjen toteutumisen myös käytännössä. Taulukko 1. Malli-näkymä-arkkitehtuurien ominaisuuksien arviointi.. Toteutettavuus Yleiskäyttöisyys Testattavuus Opittavuus Ylläpidettävyys. MVC + +++ ++ + + 8. MVP ++ ++ +++ + ++ 10. MVVM +++ ++ +++ ++ +++ 13.

(22) 16. 3 MVVM-SUUNNITTELUMALLIN ESIMERKKITOTEUTUS. Tässä luvussa käydään läpi, kuinka MVVM-suunnittelumallin mukainen esimerkkisovellus toteutetaan WPF-teknologialla. Tavoitteena on antaa lukijalle tarvittavat lähtötiedot WPF-teknologian tarjoamista ominaisuuksista MVVM-suunnittelumallin mukaisen järjestelmän toteuttamiselle. Kappaleessa 3.1 esitellään esimerkkisovelluksen ominaisuudet. Seuraavassa kappaleessa 3.2 käydään läpi WPF-teknologian ominaisuudet, jotka liittyvät MVVM-suunnittelumallin toteuttamiseen. Viimeisessä kappaleessa 3.3 kuvataan, kuinka esimerkkisovellus on toteutettu MVVM-suunnittelumallin mukaisesti.. 3.1. Puhelinluettelosovellus. Puhelinluettelosovellus on esimerkkisovellus, jonka avulla havainnollistetaan MVVMsuunnittelumallin toteutusta WPF-teknologialla. Sovelluksen suunnitteluratkaisut ja toteutusyksityiskohdat ovat peräisin kirjallisuudessa kuvatuista tavoista toteuttaa MVVM-suunnittelumallin mukainen sovellus. Tavoitteena on kuvata yksinkertainen MVVM-suunnittelumallin mukainen esimerkkisovellus ja antaa lukijalle lähtötiedot, kuinka yksinkertainen MVVM-suunnittelumallin mukainen sovellus toteutetaan..

(23) 3. MVVM-suunnittelumallin esimerkkitoteutus. 17. Puhelinluettelosovellus koostuu kahdesta näkymästä. Päänäkymä listaa tiedot sovellukseen lisätyistä yhteyshenkilöistä. Yhteyshenkilöitä voidaan hakea näkymässä annettavan avainsanan avulla. Puhelinluettelosovelluksen päänäkymä on esitetty kuvassa 7.. Kuva 7. Puhelinluettelosovelluksen päänäkymä. Toinen näkymä mahdollistaa yhteyshenkilöiden lisäämisen sovellukseen. Näkymä on esitetty kuvassa 8. Yhteyshenkilöistä voidaan tallentaa etunimi, sukunimi, puhelinnumero ja osoite.. Kuva 8. Näkymä yhteyshenkilön lisäämiseen puhelinluettelosovelluksessa..

(24) 3. MVVM-suunnittelumallin esimerkkitoteutus. 18. Puhelinluettelosovelluksen malli koostuu luokasta, joka määrittelee yhteyshenkilön tiedot. Puhelinluettelosovellukseen liittyvät tiedostot on listattu kuvassa 9.. Kuva 9: Puhelinluettelosovelluksen tiedostot.. 3.2. Windows Presentation Foundation. Windows Presentation Foundation, eli WPF on Microsoftin tarjoama uusi käyttöliittymäkirjasto, joka korvaa vanhan Windows Forms-käyttöliittymäkirjaston. Tässä kappaleessa käydään läpi WPF-teknologian tärkeimmät ominaisuudet, jotka liittyvät MVVMsuunnittelumallin toteutukseen. WPF-teknologia pitää sisällään paljon muitakin ominaisuuksia kuin tässä kappaleessa esitetyt asiat. Lisätietoja WPF-teknologiasta voi lukea seuraavista lähteistä: MacDonald, 2010; Windows Presentation Foundation, 2011. 3.2.1. XAML. WPF-teknologia tarjoaa uuden tavan määritellä sovelluksien käyttöliittymiä. WPFteknologia hyödyntää käyttöliittymien määrittämiseen XAML-kuvauskieltä (eng. Extensible Application Markup Language). XAML on XML pohjainen kuvauskieli, jolla muodostetaan puurakenne .Net olioista. XAML-käyttöliittymäkuvauksia voidaan toteuttaa graafisilla suunnittelutyökaluilla. Muun muassa Visual Studio tarjoaa graafisen suunnittelutyökalun käyttöliittymien toteutukseen. XAML-kuvauskielellä toteutettuja käyttöliittymiä on mahdollista toteuttaa myös kirjoittamalla käsin XAML-koodia. XAML-kuvauskieli ei ole ainoastaan WPF-teknologian hyödyntämä menetelmä. XAML-kuvauskielestä on olemassa useita muunnelmia, joita hyödynnetään erilaisissa käyttötarkoituksissa kuten sähköisissä dokumenteissa (XPS XAML) ja Windows Workflow Foundation elementtien määrittämiseen (WF XAML). (MacDonald 2010, ss. 2360; XAML Overview 2011.).

(25) 3. MVVM-suunnittelumallin esimerkkitoteutus. 19. WPF-teknologiassa XAML-kuvauskielen elementti vastaa aina jotain määriteltyä .Net-luokkaa. Kuvauskielen avulla .Net-luokista voidaan rakentaa puurakenne, joka kuvaa luokkien rakennetta toisiinsa. Kuvauskielien avulla voidaan rakentaa näkymiä, jotka koostuvat käyttöliittymäkomponenteista joiden sisällä on uusia käyttöliittymäkomponentteja. Luokkamäärittelyn lisäksi kuvauskielellä voidaan määritellä luokan ominaisuuksia. (MacDonald 2010, ss. 23-60.) Yksinkertainen WPF XAML-dokumentti on kuvattu esimerkissä 1. <Window x:Class="Examples.XAMLExample" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="XAMLExample" Height="300" Width="300"> <StackPanel> <TextBox Background="Gray" FontFamily="Courier New" FontSize="14" HorizontalAlignment="Right" IsReadOnly="True" Name="textBoxExample" Text="XAML example" /> </StackPanel> </Window>. Esimerkki 1. Ikkunan määritys XAML-kuvauskielellä. Esimerkistä voidaan nähdä, kuinka dokumentissa on määritelty yksi ikkuna (Window). Kaikissa XAML-dokumenteissa on määritelty nimiavaruudet xmlns ja xmlns:x, jotka määrittelevät WPF-komponenttien sijainnin sekä XAML ominaisuuksia joilla voidaan vaikutta kuvausmäärittelyn tulkintaan. Suurin osa .Net luokkien ominaisuuksista voidaan asettaa kuvauskielessä tekstimuotoisella merkkijonolla. Esimerkissä 1 TextBoxluokalle asetetaan muun muassa seuraavia ominaisuuksia Background, FontFamily, FontSize, HorizontalAlignment ja IsReadOnly. XAML kuvauksessa kaikkien ominaisuuksien arvot annetaan merkkijonolla. Todellisuudessa kaikki ominaisuuksille annetut parametrit edustavat eri tyyppejä. Background on Brush-olio. FontFamily on merkkijono, joka annetaan FontFamily-luokan rakentajalle. FontSize on integer-muuttuja. HorizontalAligment on enum-tietotyyppi. IsReadOnly on boolean-muuttuja. XAML hyödyntää ominaisuuksien asettamiseen .Net-kirjaston tyyppi muuntimia (eng. Type Converters). Automaattisen tyyppimuunnoksen ansioista XAML-kuvauskielellä voidaan pienellä määrällä tekstiä kuvata monimutkaisiakin rakenteita. (MacDonald 2010, ss. 2360.) Esimerkissä 2 on kuvattu saman ikkunan määritys käyttäen C#-koodia..

(26) 3. MVVM-suunnittelumallin esimerkkitoteutus. 20. Window window = new Window(); window.Title = "XAMLExample"; window.Height = 300; window.Width = 300; StackPanel panel = new StackPanel(); TextBox textBox = new TextBox(); textBox.Background = new SolidColorBrush(Colors.Gray); textBox.FontFamily = new FontFamily("Courier New"); textBox.FontSize = 14; textBox.HorizontalAlignment = System.Windows.HorizontalAlignment.Right; textBox.IsReadOnly = true; textBox.Name = "textBoxExample"; textBox.Text = "XAML example"; panel.Children.Add(textBox); window.Content = panel; window.Show();. Esimerkki 2. Ikkunan määritys C#-koodilla. XAML-kuvauskielen tehokkuus korostuu määriteltäessä monimutkaisempia ominaisuuksia, kuten listoja ja tiedon sitomista. Listojen esittelemiseen sekä tiedon sitomiseen palataan myöhemmin tässä työssä (ks. kappale 3.3 Puhelinluettelosovelluksen toteutus MVVM-suunnittelumallilla). XAML tiedostojen liittäminen ajettavaan ohjelmaan tapahtuu kaksivaiheisen käännöksen tuloksena. Ensimmäisessä vaiheessa XAML tiedostosta käännetään binäärinen XAML tiedosto BAML. Käännöksen yhteydessä syntyy myös g.cs-päätteinen tiedosto, joka sisältää toteutuksen, jossa ladataan käännetty BAML-tiedosto, esitellään käytetyt komponentit ja kytketään tapahtumankäsittelijät. Käännöksen toisen vaiheen suorittaa ohjelmointikielen kääntäjä, jonka tuloksena on ajettava exe-tiedosto. Käännetyt BAMLtiedostot ovat staattisia resursseja käännetyssä binäärissä. XAML-tiedostoja voidaan ladata sovellukseen myös dynaamisesti ilman kääntämistä. XAML-tiedoston lataaminen dynaamisesti on kuitenkin hitaampaa kuin käännetyn BAML-tiedoston lataaminen. XAML-tiedostojen kääntämisestä voi lukea enemmän lähteestä MacDonald (2010, s. 48-56). XAML-kuvauskielen hyödyntäminen näkymien määrittämisessä mahdollistaa sen, että näkymien toteutus ei ole sidoksissa sovelluksen sovelluslogiikan toteutukseen. XAML-kuvauskielen tarkoitus on määritellä sovelluksen käyttöliittymä niin, että se on helposti päivitettävissä ja tarvittaessa vaihdettavissa kokonaan ilman muutoksia sovelluksen sovelluslogiikkaan. XAML-kuvauskielellä toteutettu näkymä ottaa kantaa vain siihen, kuinka sovelluksen tieto esitetään näkymässä ja mitä toiminnallisuuksia käyttäjälle tarjotaan näkymästä tietomalliin. WPF-teknologian mukaan näkymä ei ole paikka, jossa sovelluksen tietoa säilytetään tai missä toteutetaan sovelluksen toiminnallisuutta..

(27) 3. MVVM-suunnittelumallin esimerkkitoteutus. 21. Avainasemassa näkymien ja sovelluslogiikan liittämisessä toisiinsa on tiedon sitominen (ks. kappale 3.2.4 Tiedon sitominen) ja tietomallin asettaminen. Tietomalli asetetaan näkymälle käyttämällä DataContext-määrettä. DataContext kuvaa näkymän tietomallia. Tietomalli toteuttaa kaikki ominaisuudet ja toiminnallisuudet, joita XAMLkuvauskiellä toteutetussa näkymässä käytetään. Näkymissä määritellään vain ominaisuuksien nimiä, joiden sisältöä halutaan näyttää näkymissä. WPF-teknoligian mekanismien avulla sovelluslogiikan toteutus voidaan kapseloida erilliseen luokkaan, jota näkymät hyödyntävät. MVVM-suunnittelumallissa tätä luokkaa kutsutaan näkymämalliksi. 3.2.2. Looginen ja visuaalinen puu. XAML-käyttöliittymäkuvauksien yhteydessä puhutaan usein sen puurakenteesta. XAML käyttöliittymä voidaan kuvata loogisena sekä visualisena puuna. Looginen puurakenne muodostuu käyttöliittymässä käytetyistä käyttöliittymäkomponenteista ja niiden rakenteesta. Sivulla 20 esitetyn esimerkin 1 muodostama looginen puu on kuvan 10 mukainen. (MacDonald 2010, ss. 119-158, ss. 499-543).. Kuva 10: Looginen puurakenne. Looginen puurakenne ei vaikuta sovelluksen toteutukseen. XAML-kuvauskielellä toteutettu käyttöliittymä muodostaa automaattisesti loogisen puurakenteen. Loogista puurakennetta hyödynnetään tapahtumien välittämiseen. WPF-teknologian tapahtumien välitystä on esitelty kappaleessa 3.2.3 Reititetyt tapahtumat. (MacDonald 2010, ss. 119158, ss. 499-543). Visuaalinen puu tarjoaa mahdollisuuden vaikuttaa käyttöliittymäkomponenttien esitystapaan. Esimerkin 1 muodostama visuaalinen puu on esitelty kuvassa 11..

(28) 3. MVVM-suunnittelumallin esimerkkitoteutus. 22. Kuva 11: Visuaalinen puurakenne. Kuvasta 11 nähdään, että visuaalinen puu tarjoaa muun muassa luokkia, joiden avulla komponentin ulkoasua voidaan muuttaa. Komponenteille voidaan asettaa tyyliresursseja, jotka kuvaavat kuinka komponentti piirretään näytölle. Staattiset tyyliresurssit mahdollistavat yhdenmukaisen ulkoasun koko sovelluksessa. Komponenteille voidaan asettaa myös ehtoja, jotka toteutuessaan asettavat komponentille tietyn tyylin. (MacDonald 2010, ss. 119-158, ss. 499-543). XAML-kuvauskielen visuaalisen puun muokkaamisesta on esimerkkejä myöhemmin tässä työssä (ks. luku 3.3.2 AddressBookMainWindow-näkymä ja luku 3.3.3 AddContactUserControl-näkymä). 3.2.3. Reititetyt tapahtumat. Reititetyt tapahtumat (eng. Routed Events) ovat WPF-teknologian uudenlainen tapa käsitellä tapahtumia. Reititetyt tapahtumat tarjoavat tehokkaan tavan määritellä tapahtumia näkymissä. Reititettyjä tapahtumia hyödynnetään muun muassa tiedon sidonnassa (ks. kappale 3.2.4 Tiedon sitominen) sekä komentojen välittämisessä näkymästä sovelluslogiikalle (ks. kappale 3.2.7 Toiminnon suorittaminen). WPF-teknologian tapahtumat voidaan jakaa kolmeen kokonaisuuteen. (MacDonald 2010, ss. 119-158). •. Suorat tapahtumat (Direct events): Perinteiset .Net ohjelmoinnissa käytetyt tapahtumat ovat suoria tapahtumia. Tapahtuma laukaistaan määritetyssä luokassa ja toiset luokat voivat sitoutua kuuntelemaan tapahtumaa toteuttamalla tapahtumankäsittelijän. Tapahtuman laukaisu ei etene muille luokille. (MacDonald 2010, ss. 119-158)..

(29) 3. MVVM-suunnittelumallin esimerkkitoteutus •. •. 23. Bubbling-tapahtumat (Bubbling events): Tapahtuman laukaisu aiheuttaa tapahtumapyyntöketjun, joka etenee loogista puurakennetta ylöspäin. Tapahtumapyyntöketjun aikana kaikki puurakenteessa määritetyt tapahtumankäsittelijät suoritetaan. Esimerkiksi MouseUp-tapahtuma on bubbling-tapahtuma. Bubblingtapahtumaa havainnollistetaan seuraavassa esimerkissä 3. (MacDonald 2010, ss. 119-158). Tunneling-tapahtumat (Tunneling events): Tapahtuma vaeltaa loogista puurakennetta alaspäin kunnes saavuttavat oman määränpäänsä. Matkan aikana tapahtumalle voidaan asettaa valmistelevia toteutuksia. Esimerkiksi PreviewKeyDown-tapahtuma on tunneling-tapahtuma. Tapahtuman eteneminen alkaa korkeimmalta tasolta loogista puuta eli ikkunasta. Tapahtuma etenee loogista puurakennetta edelleen seuraaville komponenteille kunnes saavuttaa päämääränsä. PreviewKeyDown-tapahtuman päämäärä on se komponentti jossa käyttöliittymän kohdistus oli kun painiketta painettiin. Tunneling-tapahtuman ansiosta näppäimen painallus voidaan käsitellä ylemmällä tasolla tai se voidaan estää kokonaan. (MacDonald 2010, ss. 119-158).. Reititetyt tapahtumat ovat sidoksissa WPF-teknologian tapaa määritellä näkymiä XAML-kuvauskielellä. Esimerkissä 3 on määritelty alue, joka määrittää sovelluksen otsikon. <Grid> ... <Label ... Background="AliceBlue" MouseUp="Label_MouseUp" > <Grid> ... <Image ... Source="/Examples;component/image.png"/> <Label ... Content="Demo header..." Padding="0" /> <Label ... Content="My music app" FontSize="40" Padding="0" /> <Label ... Content="Demo information..." Padding="0" /> </Grid> </Label> </Grid>. Esimerkki 3. Reititetyt tapahtumat. Otsikko koostuu Label-komponentista, jonka sisälle on määritelty yksi Imagekomponentti kuvan esittämistä varten ja kolme Label-komponenttia otsikon tekstikuvauksia varten. XAML-kuvauskielen muodostama käyttöliittymä on esitetty kuvassa 12..

(30) 3. MVVM-suunnittelumallin esimerkkitoteutus. 24. Kuva 12. Esimerkin 3 muodostama käyttöliittymä. Otsikkoaluetta painettaessa halutaan toteuttaa jotain tiettyä toiminnallisuutta. Perinteisesti .Net ohjelmoinnissa jokaiselle otsikkoalueen komponentille pitäisi määritellä MouseUp-tapahtuma ja sitoa se samaan tapahtumankäsittelijään. WPF-teknologiassa reititettyjen tapahtumien ansiosta riittää, että MouseUp-tapahtuma on määritelty ainoastaan ylimmässä Label-komponentissa. Mikäli käyttäjä painaa jotain tämän komponentin sisällä olevista komponenteista, MouseUp-tapahtuma laukeaa ja kulkeutuu bubblingtapahtumana loogista puurakennetta ylöspäin. Lopulta tapahtuma päätyy määritettyyn Label-komponenttiin, jossa on esitelty MouseUp-tapahtuman tapahtumankäsittelijä. Label-komponentissa määritelty tapahtumankäsittelijä suoritetaan ja MouseUptapahtuma jatkaa kulkuaan puurakenteessa ylöspäin. Tapahtuman kulkua voidaan seurata toteuttamalla kaikille komponenteille oma MouseUp-tapahtuman tapahtumankäsittelijä. (MacDonald 2010, ss. 119-158). Reititettyjen tapahtumien ansiosta näkymässä syntyvien tapahtumien käsittelijät voidaan toteuttaa vasta tietomallissa, joka asetetaan näkymän DataContext-määreeseen. Reititettyjen tapahtumien kulku päätyy lopulta DataContext-määreeseen asetettuun tietomalliin, jossa tarvittavat käsittelijät on toteutettu. Näin ollen näkymä ei sisällä mitään logiikkaa tai tapahtumankäsittelijöitä. Tämä mekanismi on välttämätön, jotta WPFteknologian tiedon sidonta ja komennot toimivat. (MacDonald 2010). 3.2.4. Tiedon sitominen. Tiedon sitominen (eng. Data Binding) on WPF-teknologian tarjoama ominaisuus, jonka avulla voidaan toteuttaa tiedon välittäminen näkymien ja tietomallin välillä. WPFteknologian tiedon sidonnan avulla näkymien ja tietomallin välille voidaan muodostaa vuorovaikutussuhde nopeasti ja tehokkaasti. (MacDonald 2010, ss 599-642: DataBinding 2011) Esimerkki 4 kuvaa yksinkertaista tietomallia. Esimerkissä 4 on kuvattu Contactluokka, joka toteuttaa yhden henkilön tiedot..

(31) 3. MVVM-suunnittelumallin esimerkkitoteutus. 25. class Contact { ... private string _firstName = String.Empty; public string FirstName { get { return _firstName; } set { _firstName = value; } } private string _surname = String.Empty; public string Surname { get { return _surname; } set { _surname = value; } } private string _phone = String.Empty; public string Phone { get { return _phone; } set { _phone = value; } } }. Esimerkki 4. Contact-luokan toteutus. Näkymän määrittämässä XAML-tiedostossa tiedon sidonta toteutetaan Bindingavainsanan avulla. Esimerkissä 5 on kuvattu yksinkertainen ikkuna, joka hyödyntää WPF-teknoligian tiedon sidontaa. <Grid> ... <Label ... Content="First name:"/> <TextBox ... Text="{Binding Path=FirstName}"/> <Label ... Content="Last name:"/> <TextBox ... Text="{Binding Path=Surname}"/> <Label ... Content="Phone:"/> <TextBox ... Text="{Binding Path=Phone}"/> </Grid>. Esimerkki 5. Tiedon sidonta XAML-tiedostossa. Esimerkissä 5 TextBox-komponenttien Text-kenttiin sidotaan edellä kuvatun Contact-luokan ominaisuudet. Tiedon sidonnan tärkeässä asemassa on näkymän DataContext-määre. DataContext kuvaa tietomallia, joka on näkymän käytettävänä. DataContext voidaan asettaa monelle eri tasolle. Koko näkymän käytössä oleva tietomalli voidaan asettaa esimerkin 6 mukaisesti..

No results found