Ei KommenttejaTässä osassa tarkastellaan Microsoft:n COM+-palveluiden tarjoamaa tekniikkaa hallita tietokantojen transaction-käsittelyä. Aihetta tarkastellaan suurimmilta osin käytännön näkökulmasta katsottuna, jolloin selvitetään miten kyseinen tekniikka voidaan ottaa käyttöön omassa sovelluskoodissa. Tekniikkaa on tarkoitus tarkastella lisäksi hieman sovelluksen suorituskyvyn näkökulmasta katsottuna.
aihe: dotNet
Olet varmaan joskus huomannut Windows-sovelluksia käyttäessäsi sulavasti näyttöön ilmestyviä toimintopaneeleja tai ilmoitusruutuja, jotka liukuvat hiljalleen piiloon. Tämän kaltainen käyttöliittymäkomponenttien animointi on peräisin Microsoft:n kehittämästä WPF-käyttöliittymätekniikasta, jonka tarkoituksena on ulkoisesti tarkasteltuna tarjota käyttäjilleen entistäkin rikkaampia ja mukautuvampia käyttöliittymiä. Perinteistä WinForms-käyttöliittymää voidaan yleisesti pitää WPF:ään verrattuna hyvin “staattisena”, joten uusimpaa projektia työstäessäni aloin tutkimaan mahdollisuuksia WPF-toiminnallisuuden tuomiseksi WinForms-sovellukseen.
aihe: dotNet
.NET-ympäristö tarjoaa muutamia toisistaan poikkeavia tekniikoita tietokantojen transaction-käsittelyn toteuttamiseksi. Oma näkemykseni on, että tyylin, miten tietokantakyselyiden transaction-käsittely hoidetaan, tulee mukautua kulloinkin kyseessä olevan kyselyiden sarjan tai esimerkiksi sovellusarkkitehtuurin luonteeseen. Lisäksi transaktioille saatetaan joutua asettamaan erityisiä vaatimuksia, jolloin aivan perinteisimmät tekniikat eivät enää yksinkertaisesti riitä. Esittelen siis seuraavissa “.NET-transaktiot”-blogikirjoituksissa muutamia erilaisia tekniikoita, joiden avulla on mahdollista hoitaa oman järjestelmän tietokantakyselyiden transaction-käsittely. Samalla pyrin tarkastelemaan hieman sitä, mihin erilaisiin tilanteisiin kyseiset tekniikat voisivat kulloinkin soveltua.
aihe: dotNet
Esittelin aiemmassa blogikirjoituksessani (.NET appConfig-tiedoston käsittely) yhden tavan, jonka avulla voitiin toteuttaa .NET-sovelluksen appConfig-tiedostossa olevien asetusten käsittely. Kokemani perusteella totesin kuitenkin, että kyseinen tekniikka on hieman liian monimutkainen ja sama asia voidaan suorittaa huomattavasti yksinkertaisemminkin. Monimutkaisuutensa lisäksi aiemmin esittelemäni tekniikka voi koitua ongelmaksi, kun sovellusta ajetaan Windows-järjestelmissä rajoitetuin käyttöoikeuksin. Käyttäjän oikeudet eivät siis riitä tiedostokäsittelyä toteuttavien sovellusten suorittamiseen. Ainakin kun kyseessä on Windows Vista ja sovelluksen sijaintina on “C:\Program Files\”.
aihe: dotNet
Xml-tiedostojen käsittely on yksi ohjelmoijan perustaidoista, joka korostuu entisestään, kun puhutaan tietojärjestelmien kehittämisestä. Aiheeseen tutustuminen tuli ajankohtaiseksi työskennellessäni uusimman projektini parissa, jossa ongelmaksi muodostui normaalin Winforms-sovelluksen AppConfig-tiedoston käsittely. Käsittelyn tarkoituksena oli hallita sovelluksen tietokantaan, mikä oli Access 2007 -tyyppinen, kytkeytymisessä käytettävää connectionstring-merkkijonoa. Tästä siis kannattaa huomata, että connectionstring oli tallennettuna nimenomaan AppConfig:iin.Tavoitteena oli siis se, että tietokantaan kytkeytyminen voitaisiin hoitaa riippumatta siitä, missä käyttöjärjestelmän kansiossa tietokanta sijaitsee. Connectionstring-merkkijonossa oleva Data Source:han muodostuu sen kansiopolun merkkijonosta, mistä hallittava tietokanta löytyy. On siis syytä vielä tiedostaa, että tässä tapauksessa tietokanta oli sijoitettu itse sovelluksen kansiorakenteen sisään.
aihe: dotNet
.NET:n enemmän tai vähemmän satunnaisia lukuja tuottava Random -luokka on oikein käytettynä tehokas tapa tuottaa satunnaisia lukuja, mikäli sovelluksen koodiin ei ole tarvetta kehittää omaan algoritmiin pohjautuvaa lukujen generointia. Törmäsin aiheeseen oman pienimuotoisen sudoku-peliprojektini tiimoilla ja tutkimalla .NET:n dokumentaatiota luokan käytöstä selvisi uusia piirteitä.
aihe: dotNet
