.NET kehitystä

Euroopan ohjelmistoalan järjestöt ovat listanneet Euroopan top 200 it-taloja. Listan kärjessä on tietysti Microsoft, IBM ja SAP. Kuitenkin meidän puljumme Visma on aika mukavasti siellä sijalla 45 ja puhtaasti eurooppalaisista yrityksistä sijalla 11!

Parhaimpana "suomalaisena" löytyy Tieto sijalta 54. Ystävämme Basware on sijalla 130.

 

Pitäisköhän kohta muuttaa koko otsikko? Tämä vuosi menee open source maailmassa ja toistaiseksi se näyttää hyvältä. Oikeastaan ainoa huonompi juttu on ollut, että koneen resurssit ovat kovilla, kun koneessa pyörii Microsoftin kehitysvälineet ja Java kehitysvälineet + sovelluspalvelimet ja tietokannat samanaikaisesti.

Noh, siihenkin tulee apua ensi viikolla kun pistään uuteen kannettavaani vain Ubuntu Linuxin! (En siis Windowsia. Saas nähdä miten äijän käy.)

Siirryttyäni Java-maailmaan olen ollut positiivisesti yllättynyt kuinka hyviä ilmaistyökalut ovat oikeasti olleet. Teen kehitystä pääasiassa Enterprise JavaBeans 3.0:lla (EJB3), joka on osoittautunut erittäin hyväksi ja tehokkaaksi frameworkiksi business-logiikan toteuttamiseen. Kehitysmalli ja ratkaisutavat ovat selkeitä. IDE-puolella olen käyttänyt Netbeans 6.0:aa, joka on ollut helppo oppia. Se näyttäisi lisäksi olevan aika hyvin optimoitu nimenomaan EJB3-kehitykseen. Kun pakettiin laitetaan vielä ilmainen application server (GlassFish v2) ja tietokanta (MySQL), niin koossa onkin aika paljon tavaraa, joilla palvelinpään logiikan pystyy toteuttamaan. Käyttöliittymäpuoleen en ole toistaiseksi paljoa vielä keskittynyt. Itse asiassa olen tehnyt joitakin UI-asioita vielä 'vanhoilla' Microsoft-työkaluilla. (Vanhoilla siksi, että Java-työkalut ovat minulle se uudempi maailma.) Eri teknologiat kyllä näyttävät oikeasti keskustelevan hyvin sujuvasti keskenään.

 

En olisi tätä vielä jokin aika sitten uskonut itsekään, mutta perusbusinesslogiikan toteuttamisessa EJB3-alusta on osoittautunut tehokkaammaksi tavaksi kuin .NET. EJB on suunniteltu nimenomaan businesslogiikan tekemiseen toisin kuin .NET Framework, joka on paljon geneerisempi. Siis on toisaalta hyvin ymmärrettävää, että EJB on niin hyvä tässä vertailussa... Ehkä suurin yksittäinen tekijä on EJB persistence, jonka vuoksi SQL:ää ei tarvitse enää manuaalisesti kirjoittaa. Tämä nopeuttaa ohjelmistokehitystä huomattavasti.

Viime aikoina .NET puolella on ollut hiljaista ja siihen on syynsä. Viimeiset kuukaudet olen ollut tekemisissä Java-kehityksen kanssa! Näin Microsoft-puolelta tulleena on ollut kiinnostavaa nähdä mitä kaikkea erityisesti Java + open-source puolella todella löytyy. Kun Microsoft-puoli tarjoaa useimmiten yhden tavan ratkaista asia, niin Java-puolella homma on laajempi. Vaihtoehtoisia tapoja on useita (erilaisia application servereitä, sovelluskehitys frameworkeja, peristence providereita jne.). Outoa on ollut myös huomata miten hyvää tavaraa löytyy Java puolelta ja täysin ilmaiseksi.

Tai oikeastaan se julkaistiin eilen. Moni lienee jo odotellut uutta .net frameworkia ja erityisesti LINQ:ta. - Ainakin itse olen. Lisäksi Visual Studiolla pystyy nyt tekemään eri .NET Frameworkia käyttäviä komponentteja. Taremmin sanottuna .NET Framework 2.0, 3.0 tai 3.5 -komponentteja. Ei tarvinne enää olla niin useita Visual Studioita omalla koneella.

 

 

Windows Communication Foundation (WCF) tarjoaa mahdollisuuden hyödyntää sessiopohjaisia yhteyksiä. Erityisesti kun käytetään transaktioita (transactionFlow), suositellaan käytettäväksi myös ReliableSession-määritystä. Tällöin sessioita luonnollisesti käytetään. 

 

Asiakaspuolella hyödynnetään usein ChannelFactory:ä, jolla tarvittavan proxy-luokan voi helposti luoda. Tässä on kuitenkin yksi huono puoli: se ei tarjoa Close() -metodia, jolla session voisi sulkea kun pyyntö on suoritettu. Tässä tapauksessa sessio vapautetaan vasta kun Timeout tapahtuu. (Oletusarvo taitaa olla 10 minuuttia.) Tällä tietysti voi olla huomattavia vaikutuksia resurssien käyttöön ja sessioiden varaamiseen. Session timeoutin voi toki myös määritellä esim. konfiguraatiotiedostossa binding-elementin receiveTimeout-attribuutilla.

 

Em. tapa on huono, koska se ei vapauta käyttämättömiä resursseja heti kun mahdollista. Oikeampi tapa toimia olisi sulkea sessio heti kun sitä ei enää tarvita. Mainio tapa toteuttaa tämä on hyödyntää geneeristä ClientBase-luokkaa. (http://msdn2.microsoft.com/en-us/library/ms576141.aspx) Käytännössä sitä käytetään niin, että luodaan uusi luokka, joka kytketään palvelun tarjoamaan rajapintaan:

 

esim.

 

Tämän jälkeen ko. proxy-luokka toteuttaa rajapinnan metodit suunnilleen seuraavasti:

 

 

Kun tällaista proxy-luokkaa käytetään asiakassovelluksessa, niin nyt tarjolla on Close() -metodi, jolla session voi sulkea. Helpoin tapa on kuitenkin käyttää proxy-luokkaa Using-lohkon sisällä, jolloin Close() -metodia ei tarvitse erikseen kutsua.

 

esim.

 

 

Team Foundation Server on monessa mielessä hyvä peli. "Pelkästään" versiohallinnan uudet ominaisuudet ovat jo käyttämisen arvoisia. Sen avulla on mahdollista määritellä vaatimuksia (check-in policy) versiohallintaan palautettaville tiedostoille. Voidaan esimerkiksi vaatia, että kaikki muutokset on kommentoitu ja että muutos liittyy johonkin TFS workitemiin. Lisäksi koodia voi analysoida millä keinoin tahansa, koska näitä sääntöjä voidaan ohjelmoida myös itse. Tällöin voidaan esimerkiksi tehdä erilaisia koodin tarkastuksia kunkin yrityksen käytäntöjen ja koodaussääntöjen perusteella.

 

TFS:ssä voidaan myös määritellä palvelimella tehtäviä komponenttien käännöksiä. Tällöin kun ohjelmoija palauttaa koodin versiohallintaan, voi hän tehdä käännöksen ajamalla käännöksen palvelimella (team build). Hieno juttu on myös se, että käännösten yhteydessä voidaan ajaa yksikkötestit. Tai olisi, jos se vain onnistuisi. Ongelmana nimittäin on, että tällöin täytyy kertoa ajettavat yksikkötestit testauslistana (test list). Ongelmalliseksi tämän tekee se, että esim. minulla käytössä olevalla Visual Studio 2005 Team Edition for Software Developers -versiolla ei tuollaisia testilistoja saa määriteltyä. Tätä varten pitäisi olla ymmärtääkseni versio "Team Edition for Testers". Aika typerästi paketoitu tuo Developers-versio, koska sillä saa luotua yksikkötestejä, mutta ei testilistoja!

 

Tuohon löytyy kuitenkin kiertotie. Kaikki yksikkötesit pystyy nimittäin ajamaan Visual Studio 2005 -komentokehotteessa mstest-komentorivityökalulla. Tällöin voi testien ajamisen määritellä vaikka bat-tiedostoon. Tämän jälkeen yksikkötestien ajamiseen riittää aina tuon bat'in ajaminen. Jos haluaa vielä kikkailla, niin tuon bat'in ajamisen voi laittaa esim. web servicen ja/tai web -sovelluksen taakse, jolloin sen ajaminen remotena onnistuu myös. Niin ja toki sen voi ajaa myös suoraan sen team buildin yhteydessä, mutta tällöin on huomioitava, että mstest'in käyttö on tuskastuttavan hidasta ja tällöin käännösten tekeminenkin hidastuu. Jokainen mstest-ajo kopioi kaikki tarvittavat dll:t yksilölliseen hakemistoon TestResults-hakemiston alle. Tämä lienee yksi syy siihen, että homma on niiiiiiin hidasta.

(Entä, miten saat käyttöösi Visual Studio 2005 Command Promptin? No bat-komennossa vaikka alla olevalla tavalla. Siinä on myös mstest-kutsu, joka ajaa yhden yksikkötestin.

 

 

Huom! Noita test caseja voi olla useita peräkkäin tuossa samassa mstest-kutsussa. Niiden järjestystä ei kuitenkaan voine määritellä mitenkään. Tällöin pitänee tehdä vain useampia mstest-kutsuja.
)