WebServicen luonti

Lähtökohdiltaan projektin aihe oli varsin mielenkiintoinen ja haastava, sillä ajattelin toteuttaa järjestelmän tietokannan ja client-ohjelman välisen yhteydenpidon perinteisen WebService-rajapinnan avulla. Tämän sivuston vieraskirja-osion, kuten myös koko muun sivuston, toiminnallisuus on toteutettu PHP-kielen avulla, joten luonnollisesti tarkoituksena oli, että myös sivustoon kehitettävä WebService luotaisiin PHP:n avulla. Lähdin siis liikkeelle projektin toteutuksessa yksinkertaisesti siitä, miten PHP-kielellä on ylipäätään mahdollista luoda WebService-rajapinta. Aiempaa kokemusta minulla ei ollut PHP:n osalta aiheen tiimoilta, mutta toki tiesin, että WebService-rajapinnan luonti aivan alusta alkaen on melko kivulias prosessi, jos käytössä ei ole mitään luontiin tarkoitettuja aputyökaluja, kuten Visual Studiota, tai kolmannen osapuolen tarjoamaa valmista palvelua. Olin tutustunut WebService-teknologiaan aiemmin .NET-tekniikoiden puolella, joten perusteet asiasta olivat selvillä.

Lähdin etsimään PHP:lle tarkoitettua valmista kolmannen osapuolen tarjoamaa palvelua, jonka avulla voisin luoda tarvittavan WebServicen. Pienimuotoisen kenttätutkimuksen jälkeen päädyin valinnassani NuSoap-nimiseen avoimen lähdekoodin palveluun, jonka avulla voidaan kehittää PHP-WebService-rajapintoja, jotka perustuvat WSDL 1.1, SOAP 1.1 ja HTTP 1.0/1.1 standardeihin. Palvelun lataussivustolta on mahdollista ladata myös NuSoap-kirjaston käyttöön liittyvä dokumentaatio. Lisäksi palvelun käytöstä on käyty lukuisia keskusteluja, joiden avulla on helppoa sisäistää sen hyödyntämiseen liittyvät perustason seikat.

1. Client lähettää pyynnön jonkin web-metodin suorittamisesta WebService:lle, joka vastaanottaa tunnistuksessa käytettävät salasanat ja tunnistusavaimen sekä muut parametrit.
2. WebService suorittaa pyynnön autentikoinnin.
3. Autentikointi onnistui, joten WebService suorittaa pyydetyn toiminnon mukaisen SQL-kyselyn tietokantaan.
4. Tietokantamoottori palauttaa SQL-kyselystä palautuneet tiedot WebService:lle.
5. WebService kokoaa kutsujalle palautettavat tiedot palveluun rekisteröityihin tietotyyppeihin.
6. WebService lähettää kootut tiedot client-ohjelmalle.

Koska WebService-rajapintaa voidaan pitää periaatteessa julkisena, tarkoituksenani oli luoda palveluun jonkinmoinen käyttäjän tunnistustoiminto. Palvelun jokainen SOAP-kutsu autentikoidaan siis erikseen kahden epämääräisen salasanan ja yhden vaihtuvan tunnistusavaimen avulla. Kyseiset tunnukset on lisäksi suojattu tiivisteiden avulla, kun käyttäjä lähettää ne SOAP-kutsussa verkon yli WebService:lle.

Haastavimmaksi ongelmaksi WebServicen luonnissa koitui tarvittavien tietotyyppien rekisteröinti palveluun. Ajatuksena oli siis luoda rajapintaan ilmentymä käsiteltävien tietokannan taulujen riveistä. Näiden tietotyyppien avulla siten kuljetetaan tietokannasta palautuneet rivit client-ohjelmalle tai esimerkiksi päivityskyselyn johdosta päivitettävä rivi client-ohjelmasta tietokantaan. SOAP-standardi kutsuu tämänkaltaisen toiminnallisuuden mahdollistavia tietotyyppejä nimellä “complex data type”. Käytännössä tämän tyypin tietotyyppi voi siis olla joko struktuuri (struct) tai taulukko (array). Luonnollisesti yhteen array-tietotyyppiin voidaan sijoittaa perus tietotyyppien (simple types) lisäksi esimerkiksi joukko struct-tyyppejä, jonka avulla on siis mahdollista kuljettaa esimerkiksi joukko tietokannan rivi-ilmentymiä yhdessä kokoelmassa haluttuun kohteeseen.

Client-ohjelman käyttöliittymä

(Voit avata kuvat klikkamalla hiirellä niistä. Voit löytää selvitykset kustakin näkymästä kuvien kuvateksteistä.)

Käyttöliittymän ulkoasu on tummanpuhuva. Ulkoasussa kiinnitettiin huomiota erityisesti tekstien fonttityyppiin ja -kokoon. Microsoftin perus fontti “Sans Serif” sais siis väistyä ja “Seqoe UI” otettiin tilalle. Fontin oletuskokoa kasvatettiin 10 pisteeseen. Päivämääriä käsitellään perinteisen Windows-kalenterikomponentin avulla, jonka kokoa on myös hieman kasvatettu alkuperäisestä.

Uusi vastaus kirjoitetaan erillisessä ikkunassa, jotta itse viestiä, johon vastataan, voidaan tarkastella samanaikaisesti.

Kun tunnistetiedot tallennetaan sovellukseen, ne tallettuvat samalla sovelluksen muistiin pysyvästi, jolloin niitä ei tarvitse antaa aina uudelleen, kun sovellusta käytetään myöhemmässä vaiheessa.

Sovelluksen muisti voidaan luonnollisesti tyhjentää, jolloin muistista poistetaan sinne tallennetut tunnistetiedot ja WebServicen kautta haetut tietokannan tiedot. Kun sovelluksessa ei ole hallittavaa tietoa saatavilla, käyttöliittymän tekstikentät menevät piiloon käyttäjältä. Tekstikentät menevät piiloon myös, mikäli yhtään viestiä ei ole aktivoitu käsiteltäväksi.

Noniin..ja palautetta sovelluksen ulkoasusta ja käyttöliittymän toiminnallisuudesta saa antaa. Omasta mielestäni esimerkiksi käyttöliittymän värit ovat hyvin mielikuvituksettomat (mustaa ja harmaata). Jos haluat antaa vinkkiä esimerkiksi värien käytöstä normaaleissa työpöytä-sovelluksissa, niin kommentoinnin sana on vapaa. Myös jos tiedät jotain hyviä kirjoja värien käytöstä kyseisen aiheen saralla, niin ehdotuksia voi antaa.

Yhden asian haluan vielä nostaa esille kehitetyn sovelluksen käyttöliittymästä, joka koskee myös yleisesti kaikkien Windows-sovellusten kehittämistä. Mielestäni siis Windows-käyttöjärjestelmien tarjoama oletus fonttikoko on aivan liian pieni. Miksi käyttäjien silmiä pitää siis rasittaa pienellä tekstillä? Jos olet sovelluskehittäjä, niin toivottavasti tiedostat ongelman ja et käytä pienikokoisia fontteja omassa sovelluksessasi. Itse en ainakaan tule enää niin tekemään.

Versio 2.0

Mikäli jatkan vielä kyseisen projektin parissa “tuusaamista”, niin ajatuksena on ollut, että toteuttaisin sovellukseen vielä vieraskirja-tietokannan varmuuskopiointi-ominaisuuden. Ominaisuus olisi siis mahdollista toteuttaa mitä luultavammin esimerkiksi .NET:n sarjallistamis-tekniikoiden avulla. Tällöin tietokannan palauttaminen voitaisiin hoitaa luonnollisesti siirtämällä aiemmin sarjallistettu tieto takaisin tyhjennettyyn vieraskirja-tietokantaan.

Toiminnon toteuttaminen voisi olla hyvin mielenkiintoinen operaatio sekin, mutta nähtäväksi jää löydänkö motivaation kipinän vielä itsestäni tämän osan tekemiseksi. Itselleni on siis tavanomaista, että en koske enää uudelleen valmiiksi saamiini projekteihin, vaan siirrän ne bittiarkistojen kätköihin pölyyntymään.

Käsittelin aiemmassa .NET-transaktiot-blogikirjoituksessani kahta erilaista .NET:n tarjoamaa tapaa tietokannan transaction-käsittelyn hoitamiseksi. Tähän kirjoitukseen viitaten kirjoitin pienen oikaisun aiheeseen, koska huomasin, että asiat eivät tietenkään mene aivan niin yksiselitteisesti kuin ne lyhykäisyydessään esittelin. Oikaisun voit löytää kyseisen blogikirjoituksen lopusta.

Sitten itse aiheeseen. Microsoft COM+-palvelut voidaan käsittää lyhyesti sanottuna kokoelmana komponentteja ja palveluita, joita voidaan hyödyntää esimerkiksi .NET-sovelluskehityksessä. COM+ on nimensä mukaisesti kehitysversio perinteisestä Microsoft:n COM-teknologiasta ( Component Object Model ). .NET-ympäristössä COM+-palveluihin päästään käsiksi kätevästi System.EnterpriseServices-nimiavaruuden kautta, jolloin palveluiden käyttöönottoa omassa projektissa edellyttää viittauksen asettaminen System.EnterpriseServices.dll-luokkakirjastoon. Viittauksen asettamisen lisäksi palveluiden käyttöönottoa edellyttää, että oma projektikokonaisuus on allekirjoitettu “vahvalla nimellä” ( strong key name ), sovellus on näkyvä COM-komponentteille ( COM Visible ) ja luokka on periytetty System.EnterpriseServices.ServicedComponent-luokasta.

COM+-transaction-tekniikan avulla on mahdollista luoda automaattisen transaction-käsittelyn omaavia komponentteja, joiden toteuttamien toimintojen transaction-viitekehys voi ulottua “hajautetusti” esimerkiksi eri servereillä olevien tietokantojen välille, jolloin COM+ kommunikoi MSDTC:n ( Microsoft Distributed Transactions Coordinator ) kanssa transaction-käsittelyn toteuttamiseksi. Vaikka transaction-käsittely voidaan käsittää tässä tapauksessa täysin automaattisena, niin sitä voidaan kuitenkin hallita toimintaa ohjaavien transaction-attribuuttien avulla. Attribuuttia “Required” ( C# syntaksin mukainen lause kirjoitetaan luokkamäärityksen yläpuolelle: [Transaction(TransactionOption.Required)] ) voidaan pitää suositeltuna attribuuttina, mikäli halutaan varmistaa, että objektin metodeissa toteutetaan aina transaction-käsittely. Täydellisen automatisoinnin takaamiseksi luokan metodeihin tulee asettaa vielä “AutoComplete”-attribuutti, joka sijoitetaan kunkin metodin määrityksen yläpuolelle ( C# syntaksi: [AutoComplete(true)] ). Näin siis transaction-käsittely on hyväksytty automaattisesti, jos yksikään transaction-viitekehyksen sisällä oleva metodi ei heitä poikkeusta ( throw Exception ). Mikäli transaction-luokan metodille ei aseteta “AutoComplete”-attribuuttia, niin transaction-käsittely tulee joko hyväksyä tai peruuttaa eksplisiittisesti System.EnterpriseServices-nimiavaruudesta löytyvien staattisten metodien “ContextUtil.SetComplete” tai “ContextUtil.SetAbort” avulla. Seuraavasta linkistä voit tarkastella pientä koodiesimerkkiä, joka edustaa kuvitteellista “Henkilö”-luokkaa sovelluksen tietokantarajapinnassa. Tähän luokkaan on luotu automaattinen transaction-käsittely COM+-palveluiden avulla.

C#: COM+-cHenkilot

Kuten edellisestä esimerkistä voidaan huomata, niin kyseisellä tekniikalla on hyvin helppoa luoda korkean luotettavuuden omaavia tietokantakomponentteja, jolloin transaction-käsittelyn toteutus voidaan “ulkoistaa” COM+-palvelun hoiteisiin. Olen kuitenkin lukenut muutamia keskusteluja liittyen kyseisen tekniikan käyttöön ja olen saanut sen käsityksen, että palvelun käyttö lisäisi kohtuuttomasti sovelluksen suorituskykytarvetta. Tein siis pienen testiohjelman, joka päivittää identtisillä kyselyillä paikallisessa SQL Server -tietokannassa olevia tauluja “normaalin” SqlClient-DataProvider:n ja COM+-palvelun tarjoamien transaction-käsittelyiden avulla. Sovellus mittaa kyselyiden suorittamiseen kulunutta aikaa ja listaa kestot perinteiseen ListBox-komponenttiin. Tämän testiohjelman tulosten perusteella voidaan ainakin todeta, että kun COM+-kysely on suoritettu ensimmäisen kerran, niin seuraavien suorituskertojen kestot ovat melkolailla samaa luokkaa mitä normaalin transaction:n avulla tehdyt. Kunkin toiminnon ensimmäiset suorituskerrat eivät siis ole vertailukelpoisia, koska näissä tapauksissa täytyy ottaa huomioon .NET:n JIT-käännöksen (Just-In-Time) luonne, jolloin prosessorin suorittamaa “NativeCode”-konekieltä ei ole vielä luotu. Testin tuloksia voit tarkastella klikkaamalla allaolevasta kuvasta.

Testisovelluksen antamat toimintojen suoritusajat.

Ajatuksena oli siis kehittää esiin ja piiloon sulavasti liukuva paneeli, joka pitää sisällään yhden ListBox- ja kaksi perinteistä Label-komponenttia. Kyseistä kokonaisuutta käytettäisiin siten hyväksi sovelluksen avulla tarkasteltavien vieraskirja-viestien selaamiseen. Voin paljastaa jo tässä vaiheessa, että koko projektin tarkoituksena on kehittää pieni Windows-sovellus, jonka avulla voin käsitellä tämän sivuston vieraskirja-osiossa olevia viestejä suoraan oman kotikoneeni työpöydältä. Tulen kirjoittelemaan tänne blogiin myös myöhemmin jotain juttua kyseisestä projektista, joten siitä ei sen enempää tässä vaiheessa.

Käytännössä WPF-toiminnallisuuden tuominen WinForms-sovellukseen on tehty hyvin yksinkertaiseksi toteuttaa .NET-ympäristössä ja sen vuoksi aiheesta löytyy useita hyviä kirjoituksia Internetin syövereistä ( Esimerkiksi tämä ). Käytännössä siis edellämainitusta tutoriaalista tulee ymmärtää seuraavat seikat: WPF-toiminnallisuus tulee toteuttaa erillisessä WPF User Control -projektissa ja WinForms-sovellukseen, johon WPF-komponentti liitetään, tulee lisätä Element Host -kontrolli, joka toimii alustana liitettävälle komponentille. Luonnollisesti myös se tekniikka, jonka avulla WPF-komponentti liitetään Element Host:iin, tulee ymmärtää. Tarkemmin ottaen liitos voidaan suorittaa useamman erilaisen menettelyn kautta. Se voidaan siis tehdä siten, että samaan sollution-kokonaisuuteen, missä myös kohteena oleva WinForms-projekti sijaitsee, lisätään uusi (Add -> New Project…) tai jo olemassa oleva (Add -> Existing Project…) WPF User Control -projekti. Tämän jälkeen WPF-kontrolli voidaan lisätä Element Host:iin Visual Studio:n designer:n kautta. Itseäni kiinnosti kuitenkin lähinnä se, miten ulkoiseksi dll-tiedostoksi käännetty WPF-komponentti liitetään Element Host:iin.

WPF-kontrolli voidaan liittää Element Host:iin Visual Studio:n designer:n kautta, jos kontrollista on luotu
oma projekti samaan sollution-kokonaisuuteen, missä liitoksen kohteena oleva WinForms-projekti on.

Mikäli liitettävä WPF-komponentti on siis käännetty dll-tiedostoksi, joka on hyvin todennäköistä hyödynnettäessä esimerkiksi kolmannen osapuolen valmistamaa komponenttia, niin liitos Element Host:iin tulee suorittaa sovelluksen koodissa. Liitoksen tekeminen koodissa onnistuu kätevästi hyödyntämällä Element Host:n Child-ominaisuutta. Käytännössä siis ensin asetetaan projektiin viittaus (reference) ulkoiseen käännetyn WPF-kontrollin dll-tiedostoon, jonka jälkeen kontrolli instannoidaan esimerkiksi kohteena olevan luokan alussa ja asetetaan Element Host:n Child-ominaisuuteen..Helppoa!

Ulkoiseksi dll-tiedostoksi käännetty WPF-komponentti otetaan käyttöön sovelluksen koodissa instannoimalla se ensin
luokkakoodin alussa (1) ja sen jälkeen asettamalla instannoitu objekti esimerkiksi luokan konstruktorissa Element Host:iin (2).
Tämän jälkeen WPF-komponentin metodeihin ja tapahtumiin päästään käsiksi instannoidun objektin kautta (3).

Alapuolelta löytyvien linkkien kautta voit tarkastella vielä aiemmin mainitsemaani projektiin luodun WPF-kontrollin XAML- ja C#-koodeja. Toteutin liu’uttamis-animaation C#-koodin avulla, mutta yhtä hyvin se oltaisiin voitu tehdä tässä tapauksessa myös XAML:n avulla. Alapuolelta löytyy myös kuva, mistä voidaan huomata käyttöön otetun WPF-kontrollin ulkoasu.

XAML: CustomMessageManager C# (Code-Behind): CustomMessageManager

Käyttöön otettu WPF-kontrolli löytyy kuvan oikeasta yläosasta. Kontrolliin kuuluu yksi ListBox-komponentti ja kaksi Label-komponenttia, jotka voidaan piilottaa tai tuoda esille liu’uttamis animaatiolla höystettynä.

Ensimmäisenä esiteltävistä transaction-tekniikoista tarkasteluun otetaan .NET:n Data Provider:ien tarjoamat perinteisimmät transaktiot ja .NET Framework 2.0:n tarjoama System.Transactions.TransactionScope-transaktioluokka. Kyseisten tekniikoiden huomattavin ero liittyy niiden kykyyn hallita useamman tietokantayhteyden transaktioita. Data Provider:ien tarjoamien transaktioiden avulla voidaan siis hallita ainoastaan tietokantakyselyitä, joissa käytetään yhteen tietokantaan kohdistuvaa tietokantayhteyttä. System.Transactions.TransactionScope-palvelun avulla voidaan sen sijaan hallita lisäksi niin sanottuja “hajautettuja transaktioita” (distributed transactions), jolloin tietokantakyselyiden yhteydet kohdistuvat eri tietokantoihin. Puhuttaessa hajautetuista transaktoista voidaan usein törmätä teknologiaan nimeltä “MSDTC” (Microsoft Distributed Transactions Coordinator). Kyseinen teknologia toimii hajautettujen transaktoiden koordinaattorina, joka valvoo transaktion toteutumista useamman tietokannan välillä ( aiheesta lisätietoa ).

Miksi sitten käyttäisin perinteistä Data Provider:ien transaktio-mallia, kun tarjolla on suoraan TransactionScope-palvelun tarjoama tekniikka useamman tietokantayhteyden transaktioon? Syy tähän saattaisi löytyä esimerkiksi siitä, että Data Provider:t (esim. SqlClient, OleDb, Odbc, OracleClient) on suunniteltu toimimaan nimenomaan kullekkin Provider:lle tarkoitetun tietokannan kanssa, joten suorituskyky transaktoiden kohdalla on myös varmasti parhaimmillaan. Itse pyrin luomaan transaktiot esimerkiksi siten, että mikäli kyseessä on yksinkertainen yhdessä metodissa suoritettava kysely tai kyselyiden sarja, niin hyödynnän perinteistä transaktio-mallia. Mikäli sitten tietokantakyselyt suoritetaan useamman eri metodin kautta, niin hyödynnän TransactionScope-palvelun transaktio-tekniikkaa. Tällöin kyselyissä käytettävää tietokantayhteyttä ei tarvitse siis kuljettaa metodilta toiselle, joka tukee varmasti aina sovelluksen arkkitehtuurin eheyttä paremmin.

Lopuksi jotta kukaan ei jäisi kylmäksi, esittelen pienen perustason koodiesimerkin, missä havainnollistetaan esiteltyjen transaction-tekniikoiden käyttöä. Koodi on kommentoitu hyvin, joten siitä pitäisi olla helppoa ymmärtää ydin ajatukset.

Transaction-esimerkki

Postaukseen lisätty oikaisu 2.10.2010:

Tämähän ei siis pidä täysin paikkaansa, sillä ADO.NET:n tarjoamien transaktioiden avulla voidaan hallita myös “hajautettuja transaktioita” käyttämällä hyväksi tietokantayhteys-objektin (esim. SqlConnection) EnlistTransaction-metodia, joka tuli uutena .NET:n piiriin .NET-framework 2.0:n myötä. Tämän myötä voidaan siis todeta, että suurin ero ADO.NET:n ja System.Transactions transaktoiden välillä liittyy niiden tapaan muodostaa transaction-käsittelyn “viitekehys”. ADO.NET:n transaktoita voidaan siis pitää tässä suhteessa “manuaalisena”, jolloin uusien tietokantayhteyksien liittäminen transaction-kehykseen täytyy suorittaa manuaalisesti, kun taas System.Transactions.TransactionScope liittää aina automaattisesti kaikki viitekehyksen piirissä avatut tietokantayhteydet samaan kehykseen. Viitekehyksellä tarkoitan tässä tapauksessa sitä kehystä, jonka piirissä valvotaan transaction-käsittelyn onnistumista (comit), jolloin virheiden ilmaantuessa kaikki tehdyt toiminnot kehyksen sisällä peruuntuu (rollback).

Sovellusasetukset voidaan siis luoda melko yksinkertaisesti suoraan Visual Studio:n (Visual Studio 2008) asetusten designer:n kautta (Properties –> “projektin nimi” Properties… –> Settings-välilehti).

Ennen asetusten luontia Settings-välilehden asetuksista on syytä ymmärtää muutama tärkeä seikka. Asetusten “Name”-attribuutti tarkoittaa siis asetuksen nimeä, jonka avulla ohjelmakoodissa voidaan viitata haluttuun asetukseen. “Scope”-attribuutti sen sijaan tarkoittaa asetuksen tyyppiä, johon voidaan asettaa kaksi erilaista arvoa. Mikäli arvoksi siis asetetaan “User”, niin luotu asetus on käyttäjäkohtainen kaikille Windows-järjestelmän käyttäjille erikseen. Tämän lisäksi asetukset tallentuvat erilliseen xml-tiedostoon käyttöjärjestelmän kansioon: “%systemroot%\Documents And Settings\%username%\Local Settings\Application Data\%Company%\”. Edellä mainitun polun “%Company%” tarkoittaa .NET-sovelluksen (C#-sovellus) “AssemblyInfo.cs”-tiedoston attribuutin “[assembly: AssemblyCompany("????")]” arvoa. Mikäli “Scope”-attribuutin arvoksi sitten asetetaan “Application”, niin asetus on sovelluskohtainen ja kaikille käyttäjille yhteinen. Erikoista tämän arvon saaneille asetuksille on, että kyseistä asetusta ei voi muokata sovelluksen ajonaikana (ainakaan suoraan!).

Seuraavaksi on vuorossa pienimuotoinen esimerkkisovellus, jossa käsitellään sovelluksen appConfig-tiedostoon luotuja asetuksia. Asetukset on luotu Visual Studio:n settings designer:n kautta (voit nähdä luodut asetukset aiemmasta kuvasta). Asetuksiin “form_locationX” ja “form_locationY” on tarkoitus tallentaan sovelluksen pääikkunan sijainti, kun käyttäjä painaa painiketta lomakkeelta (koodissa tapahtuma “btnTallenna_Click”). Kun sovellus sitten seuraavan kerran käynnistetään, niin pääikkuna avautuu asetustiedostosta löytyvien kordinaattien osoittamassa sijainnissa. Sovelluksen koodin toisessa painiketapahtumassa (”btnTuo_Click”) sen sijaan asetetaan sovelluksen asetuksista löytyvään “csTestitietokanta”-connectionstring:iin puuttuva data source. Kyseisen asetuksen “Scope”-attribuutille on annettu arvo “Application”.

Koodeista kannattaa huomata tekniikka, jonka avulla “Application”-tyypin asetusta voidaan muokata ajonaikana. Opin tekniikan katsomalla MSDN-sivustosta löytyvän videon, jossa kyseinen tekniikka esitellään. En siis selosta kyseistä tekniikkaa tässä sen enempää, koska video havainnollistaa sitä riittävän hyvin. Voit tarkastella esimerkkikoodeja klikkaamalla alla olevia linkkejä.

appConfig-tiedosto: Tiedosto joka on syntynyt Visual Studio:n settings designer:n kautta tehtyjen asetusten johdosta.

Settings.cs-tiedosto: Tiedostoon on luotu itse tehty ominaisuus, jonka avulla voidaan muokata “Application”-tyypin asetusta sovelluksen ajonaikana.

Esimerkkisovelluksen päälomakkeen koodi: Asetuksiin päästään käsiksi C#-kielessä nimiavaruuden “Properties.Settings.Default” kautta. Asetuksiin tehdyt muutokset voidaan tallentaa saman nimiavaruuden “Save()”-metodin avulla. On huomattava, että “Application”-tyypin asetuksia ei voida tallentaa pysyvästi, vaan tämän tyypin asetuksiin tehdyt muutokset ovat voimassa vain sovelluksen istunnon ajan.

Mikäli tätä tekniikkaa verrataan aiemmin esittelemääni, niin voidaan todeta huomattava ero muun muassa asetuksien käsittelyn yksinkertaisuudessa. Tätä tekniikka noudattaessa oma sovellus on lisäksi hieman vakaampi toiminnaltaan. Sovellusta voidaan siis ajaa rajoitetuin käyttöoikeuksin, joka on merkittävä osa Windows-järjestelmän tietoturvaa. Lisäksi sovellusten käyttäjät varmasti arvostavat sitä, että juuri heidän omat asetuksensa säilyvät aina muuttumattomana. Mikä voi olla ärsyttävämpää kuin asetusten virittäminen aina uudelleen toisen käyttäjän jäljiltä.

Pelin pääikkuna. Sudokuluvut lisätään ruudukkoon itsetehdyn .NET:n User Control -komponentin avulla. Peli mittaa lisäksi sudoku-ongelman ratkaisemiseen kulunutta aikaa. Pelaajalla on yksi mahdollisuus tarkastaa syöttämiensä sudokulukujen oikeellisuus.

Mikäli sudoku-ongelman ratkaisemiseen kulunut aika on kyllin hyvä, niin se palkitaan pääsyllä Top5-listaan.

Pelin Top5-lista parhaat tulokset. Tulokset voidaan myös palauttaa, jos mieli niin tekee. Tulokset tallennetaan käyttöjärjestelmässä pelin kansiorakenteeseen olioiden sarjallistamis-tekniikan (serialization) avulla.

Jos GameOver alkaa sapettamaan ja pelaaja haluaa kaivaa syitä pelin epäonnistumiseen, niin sen voi tehdä vertaamalla omaa ja oikeaa vastausta.

Tälläistä siis tällä kertaa! Itse pelin ohjelmointiprosessista voisin kuitenkin kertoa muutaman sanan. Nimittäin ylivoimaisesti suurimmaksi ongelmaksi projektin työstämisessä muodostui odotetusti pelimoottorin logiikan ohjelmointi, mihin kuuluu sudokulukujen (itse pelin ratkaisuluvut) ja pelaajalle näytettävien vihjelukujen generoinnit. Kaikki sudokulukuja tarkemmin tutkineet tietävät siis esimerkiksi, että sudokun vaikeusastetta ei voida määritellä pelkästään pelaajalle näytettävien vihjelukujen määrän pohjalta, vaan enemmänkin niiden sijoittelun perusteella. Tämänkin vuoksi pelimoottorille piti siis kehitellä pienimuotoinen tekoäly, jonka avulla lukujen generoinnit suoritetaan.

Sudokujen ratkaisulukujen generointi toteutettiin perinteisien olio-ohjelmoinnin menetelmien avulla. Jokaisesta numeroruudukon 9×9 alueesta muodostettiin siis omat luokat, joissa käsitellään vain kullekkin alueelle kuuluvia numeroita. Tämän avulla eteentulevat ongelmat voitiin pilkkoa pienempiin kokonaisuuksiin, jolloin niiden hallitseminen on helpompaa. Ruudukon jakaminen ei kuitenkaan vielä riittänyt ratkaisemaan lukujen käsittelyyn liittyviä erilaisia tilanteita, joten projektiin luotiin erillinen “staattinen” moduli, joka oli suoraan käytettävissä kaikissa luokissa. Tähän moduuliin ohjelmoitiin siis kaikille luokille yhteisiä metodeja ja ominaisuuksia, joiden avulla lukuja voidaan käsitellä halutulla tavalla.

Pelaajalle näytettävien vihjelukujen generointi pyrittiin toteuttamaan taas siten, että pelattavat sudokut olisivat melko helppoja. Tämä toteutettiin siten, että vihjelukuja paljastetaan melko paljon käyttäjälle ja kullekkin 9×9 numeroalueelle määrätään satunnaisesti oma määrä näytettäviä vihjelukuja. Kun alustava vihjelukujen generointi on suoritettu, pelimoottori pyrkii siirtelemään lukuja hieman erilleen toisistaan, mikäli ne ovat liian lähekkäin. Siirtelyn logiikka perustuu siihen, että moottori pyrkii välttämään tilanteita, joissa vihjelukuja on vierekkäin kolme kappaletta joko vaaka- tai pystysuunnassa. Se kuitenkin voi sallia joissain peleissä kolmen vierekkäisen vihjeluku-ryhmän esiintymisen maksimissaan 3 kertaa. Olen huomannut, että tämä ei toimi aina ja sen vuoksi kolmen ryhmiä voi olla joissain peleissä enemmänkin.

Mitä uutta sitten opin projektia työstäessäni? Jos keskittymiskyvyn ja itsehillinnän harjaantumista ei lasketa, niin .NET:n piirtonimiavaruudet (System.Drawing ja System.Drawing.Drawing2D) tulivat joissain määrin tutummiksi. Lisäksi tutustuin ensimmäistä kertaa omien käyttöliittymäkomponenttien luontiin, josta voidaan todeta, että: “seKIN on tehty mukavan helpoksi”.

Tässäpä oli pienimuotoinen esittely projektista. Jos mielesi tekee nyt pelata peli tai pari uutta “Kahvikuppi-SuDoKua”, niin saamasi pitää. Voit ladata pelin alla olevasta linkistä. Latauspaketti sisältää ainoastaan pelin käynnistämiseen vaadittavan exe-tiedoston. Peli luo Top5-tuloksia varten automaattisesti yhden tiedoston samaan kansioon, missä itse exe sijaitsee. Peliä on testattu Windows XP -ja Vista -käyttöjärjestelmissä, joten toiminta esimerkiksi Windows 7:ssa on epävarmaa.

Sudoku_Released1.1.exe

Ennen kun ryhdyin koodaamaan AppConfig-tiedoston käsittelyä, niin pyrin selvittämään itselleni, mistä itse tiedosto löytyy ohjelman ajon aikana. .Net-ympäristö toimii siis Winforms-sovellusten kohdalla siten, että kun sovellus käännetään, niin samalla Config-tiedostosta muodostuu “ohjelman nimi”.exe.config niminen kopio samaan kansioon, missä sovelluksen exe-tiedosto sijaitsee. Tämä Config-tiedosto on siis se, mihin tiedostokäsittely tulee kohdistaa.

Seuraavaksi on syytä siirtyä havainnollistamaan sitä, miten selvitin käsiteltävänä olevan ongelman. Esittelen tässä siis hallittavan Config-tiedoston koodin, joka on kirjoitettu xml-kielellä, ja itse C#-kielellä ohjelmoidun testiohjelman koodin, millä tiedostonkäsittely hoidetaan. Testiohjelmasta mainittakoon sen verran, että xml-käsittely hoidetaan koodissa .Net-luokan “XmlDocument” avulla. Config-tiedoston sisältö siis ladataan XmlDocument-luokasta istannoituun olioon, jonka jälkeen tiedostoa käsitellään halutulla tavalla foreach-silmukoissa perinteisen merkkijonojen käsittelyn avulla. Voit tarkastella koodeja klikkaamalla allaolevia linkkejä.

Testiohjelma Config-tiedosto

Testiohjelman koodista (rivit 139-140) kannattaa huomioida erityisesti se, miten tehdyt muutokset tallennettiin config-tiedostoon. Tässä siis “RefreshSection” -metodin parametriksi annetaan “configuration”, jolloin tiedostossa olevien configuration-tagien välissä oleva sisältö virkistetään eli otetaan uudet muutokset käyttöön. Tässä tapauksessa koko tiedoston sisältö siis virkistetään. Tämä on tarpeellista erityisesti silloin, jos muutoksia kohdistetaan config-tiedostoon, joka on kryptattu (salattu). Se miten salaaminen sitten toteutetaan, on oma aiheensa erikseen ja sitä ei tässä yhteydessä käsitellä. Tästä kuitenkin voidaan ymmärtää, että kun connectionstring on sijoitettu esimerkiksi ohjelman config-tiedostoon, niin siihen voidaan kohdistaa erilaisia sovelluksen tietoturvatasoa nostavia toimenpiteitä.

Karkeasti sanottuna käsiteltävän tekniikan avulla voidaan siis suorittaa minkä tahansa luokkarakenteessa olevan luokan yksittäinen metodi ilman, että tarvitsee tietää minkä tyyppinen käsiteltävä luokka on. Pieninä ehtoina on kuitenkin, että käsiteltävien luokkien tulee olla periytetty (inherit) samasta kantaluokasta ja suoritettava metodi tulee löytyä kantaluokasta, jolloin sen tulee olla ylikuormitettu (override) periytetyissä luokissa. Tämän lisäksi itse koodilauseessa, missä suoritetaan satunnaisen olion ylikuormitetun metodin kutsu, tehdään implisiittinen kantaluokka-tyyppimuunnos (implicit type conversion), missä siis periytetyn luokan tyyppinen olio muunnetaan (cast) sen kantaluokan tyyppiseksi.

Seuraavan esimerkin tarkoituksena on havainnollistaa käsiteltävää tekniikkaa. Luodussa esimerkkisovelluksessa generoidaan JList-komponenttiin napin painalluksesta henkilöauto- tai kuorma-auto-olioita, mistä valintoja tekemällä voidaan tulostaa kulloinkin aktivoidun olion tiedot JTextArea-komponenttiin. Ongelmana sovelluksen koodin toteutuksessa on, että miten kulloinkin aktivoidun olion tietojen tulostus metodia kutsutaan, jos tutkimuksia siitä, minkä tyyppinen olio on, ei saa tehdä. Voit huomata sovelluksen toimintaperiaatteen alla olevasta kuvankaappauksesta.

“Generoi ajoneuvo” -napista generoidaan ajoneuvo oikeassa reunassa olevaan “ajoneuvo” -listaan, josta voidaan tulostaa olioiden tietoja alla olevaan “ajoneuvon tiedot” -kenttään.

Voit tarkastella alla olevista linkeistä esimerkkisovelluksen ohjelmakoodia. Luokka “cAjoneuvo” toimii kantaluokkana luokille “cHenkiloauto” ja “cKuormaauto”, joista sovellus generoi “ajoneuvo” listaan vietäviä olioita. Luokkien “Tiedot()” -metodin avulla suoritetaan tietojen tulostus ja esimerkkikoodeista voidaan huomata, että metodi on toteutettu kaikissa luokissa (periytetyissä luokissa ylikuormitettuna). Testiohjelman koodista kannattaa huomata tapahtuman “jLstAjoneuvotValueChanged” koodi, missä suoritetaan metodikutsu, joka vie olion tiedot alaosassa olevaan tekstikenttään..

cAjoneuvo cHenkiloauto cKuormaauto Testiohjelma

Lauseella “(cAjoneuvo)oList.get(intSelectedIndex)).Tiedot()” suoritettiin siis vuorossa olevan olion tietojen tulostus. Tutkimuksia siitä, minkä tyyppisen olion ArrayList-olio (oList) kulloinkin sisälsi, ei siis tarvittu. Erityisen hyödylliseksi tämä tekniikka tulisi silloin, kun eri tyyppisiä olioita olisi esimerkiksi useita kymmeniä.

Olioteorioiden ja -tekniikoiden ymmärtäminen on modernin ohjelmakoodin edellytys ja niiden avulla voidaan luoda helposti ylläpidettäviä ohjelmakokonaisuuksia. Toisaalta väärin käytettynä niistä voi olla haittaakin.

Mitä Timo Kallio -ple:ltä on sitten tulevaisuudessa odotettavissa? Ajatuksena on ollut kehitellä paremmaksi ainakin kirjatietokantaa ja vieraskirjaa. Kirjatietokantaan siis suunnitteilla on ollut ominaisuus, minkä avulla kirjoja voidaan selata kategorioittain. Lisäksi perinteiset selauspainikkeet saattavat poistua käytöstä, koska mielestäni niiden käyttö on hankalaa ja rajoittaa tiedon tarkastelun ainoastaan yhteen kirjaan kerralla. Vieraskirja sen sijaan saa tulevaisuudessa luultavasti osakseen ominaisuuden, mikä näyttää kommentoijien ilmoittamia sivusto-osoitteita erillisessä tilassa. Tämän avulla palautteenantajan sivusto saa huomiota enemmän osakseen ja samalla voin myös itse helpommin huomata ketkä ovat olleet kiinnostuneita kommentoimaan sivuston sisältöä.

Sivuston ulkoasusta on tullut palautetta niin puolesta kuin vastaankin. Yksinkertaisuus ja käytetty värimaailma ovat herättäneet selvästi ajatuksia ja on hienoa saada kommentteja erityisesti väreistä. Sivuston yksinkertaisuutta en tule muuttamaan, mutta luultavammin jossain vaiheessa uusia värejä ja pieniä tyylimuutoksia saattaa olla luvassa. Sivuston ilmiasu ei siis tällähetkellä ole se kaikkein tärkein kehityksen kohde.

Kaikkien muiden kehitysideoiden toteuttamisen lisäksi yritän pitää yllä jonkinmoista tahtia sisällön tuottamiseen niin blogiin kuin arkistoonkin. Tähän ei tuo yhtään helpotusta se, että aloitan työskentelyn uuden asiakaslähtöisen projektin parissa juuri parhaillaan. Huomasithan muuten uuden harjoitustyöesittelyn arkistossani? Panostin tähän työhön melko paljon, sillä .NET ja SQL Server ovat erittäin mielenkiintoisia aihealueita.