ASP.NET Core MVC on suosittu Model-View-Controller (MVC) -suunnittelumallin toteutus, joka on laajalti käytetty monimutkaisten verkkosivustojen kehittämisessä. MVC-mallissa liiketoimintalogiikka, käyttäjärajapinta ja käyttäjän syöte käsitellään erikseen, mikä helpottaa sovelluksen hallittavuutta ja laajennettavuutta. ASP.NET Core tarjoaa tehokkaan alustan verkkosovellusten rakentamiseen, ja MVC-mallin avulla voidaan kehittää skaalautuvia ja huollettavia järjestelmiä. MVC-arkkitehtuurin avulla voi rakentaa selkeitä ja helppokäyttöisiä käyttöliittymiä, joiden takana on tehokas ja modulaarinen palvelinpuolen logiikka.

Razor-luokkakirjastot puolestaan tarjoavat tavan paketoida uudelleenkäytettäviä toiminnallisuuksia ASP.NET Core -projekteihin, mukaan lukien käyttöliittymäkomponentit. Tällöin voidaan luoda komponentteja, joita voidaan helposti käyttää eri projekteissa ilman, että koodia tarvitsee kirjoittaa uudelleen.

Blazor on moderni kehys, joka mahdollistaa käyttöliittymäkomponenttien rakentamisen C#-kielellä ja .NET-ympäristössä, ja sen avulla voidaan luoda interaktiivisia verkkosivustoja ja sovelluksia ilman JavaScript-pohjaisia käyttöliittymäkehyksiä, kuten Angularia, Reactia tai Vue.js:ää. Blazor WebAssembly -teknologia suorittaa koodin suoraan selaimessa, aivan kuten JavaScript-pohjainen kehys. Blazor Server puolestaan suorittaa koodin palvelimella ja päivittää verkkosivut dynaamisesti. Blazor on monipuolinen työkalu, joka ei rajoitu pelkästään verkkosivustojen rakentamiseen. Sitä voidaan käyttää myös hybridisovellusten luomiseen mobiililaitteille ja työpöytäsovelluksille, kun sitä yhdistetään .NET MAUI:hin.

Verkkosovellusten ja palvelujen rakentamisessa käytetään useita teknologioita, jotka soveltuvat eri tarpeisiin. Yksi vaihtoehto on käyttää monoliittisia palveluja, joissa kaikki asiakasohjelman tarvitsema toiminnallisuus on yhdistetty yhteen palveluun. Toinen vaihtoehto on mikropalveluarkkitehtuuri, jossa pienemmät palvelut käsittelevät rajattuja toimintoja, ja nämä voivat kommunikoida keskenään. Kolmas vaihtoehto on nanoservice, joka tarjoaa yksittäisen toiminnon palveluna. Nanoservicet ovat yleensä inaktiivisia suurimman osan ajasta, ja ne käynnistyvät vain tarvittaessa resurssien ja kustannusten optimoinnin vuoksi.

Verkkopalvelut, jotka käyttävät HTTP:tä kommunikaatioteknologiana ja noudattavat Roy Fieldingin REST-arkkitehtuurin suunnitteluperiaatteita, ovat yleisimpiä ja niitä käsitellään tarkemmin myöhemmin kirjassa. Näiden lisäksi käsitellään myös muita verkkopalveluja, kuten:

  • gRPC: tehokkaiden ja suorituskykyisten mikropalveluiden rakentaminen, joka tukee lähes kaikkia alustoja.

  • SignalR: reaaliaikaisen viestinnän toteuttaminen komponenttien välillä.

  • OData: tietomallien, kuten Entity Framework Coren, paketointi verkkopalveluiksi.

  • GraphQL: asiakasohjelman mahdollisuus ohjata, mitä tietoja eri lähteistä haetaan.

  • Azure Functions: palvelimettomien nanoservicetien isännöinti pilvessä.

Windows Communication Foundation (WCF) oli vuonna 2006 julkaistu .NET Frameworkin osa, jonka avulla oli mahdollista luoda hajautettuja sovelluksia. WCF mahdollisti liiketoimintalogiikan erottamisen viestintäinfrastruktuurista, mikä teki mahdolliseksi viestintämekanismien vaihtamisen tarpeen mukaan. Microsoft ei kuitenkaan päättänyt tuoda WCF:tä moderniin .NET:iin, vaan sen sijaan Core WCF, yhteisön hallinnoima avoimen lähdekoodin projekti, mahdollistaa WCF:n käytön myös nykyisissä .NET-sovelluksissa.

Kun tarkastellaan verkkosovellusten ja mikropalveluiden arkkitehtuuria, on tärkeää valita oikea teknologia riippuen tarpeista ja käytettävistä resursseista. Esimerkiksi:

  • Public services: HTTP/1.1-pohjaiset palvelut ovat parhaita julkisille palveluille, joita voidaan käyttää selaimessa tai mobiililaitteessa.

  • Public data services: OData ja GraphQL soveltuvat erinomaisesti monimutkaisten ja hierarkkisten tietojen esittämiseen, jotka voivat tulla eri tietovarastoista.

  • Service-to-service communication: gRPC on optimaalinen valinta mikropalveluiden sisäiseen viestintään, koska se on tehokas ja tarjoaa matalan viiveen.

  • Real-time communication: SignalR on tehokas valinta reaaliaikaiseen viestintään useiden asiakkaiden välillä.

Erilaiset viestintäteknologiat, kuten gRPC ja SignalR, tarjoavat erinomaisia ratkaisuja moniin sovellustarpeisiin, mutta niiden tehokkuus vaihtelee sen mukaan, minkälaista viestintää sovellus tarvitsee. SignalR on erityisen hyvä valinta, kun halutaan tukea reaaliaikaisia viestejä useiden käyttäjien välillä, mutta se ei ole yhtä tehokas kuin gRPC, joka on suunniteltu matalan latenssin ja suuren läpimenon tarpeisiin.

GRPC on erittäin tehokas erityisesti silloin, kun on tarve pienentää viestien kokoa ja optimoida verkon kaistanleveyttä. Tämän vuoksi se soveltuu hyvin ympäristöihin, joissa kaistanleveys on rajoitettu. Näin ollen gRPC:n käyttö on erityisen suositeltavaa, kun rakennetaan palveluja, joissa pienet tiedostot ja nopea viestintä ovat tärkeitä.

Kun tarkastellaan nanoservicen rakentamista, kuten Azure Functionsia, on tärkeää huomata, että nämä palvelut eivät tarvitse olla käynnissä koko ajan. Ne voivat olla inaktiivisia, mikä tekee niistä kustannustehokkaita ja resursseja säästäviä ratkaisuja.

Endtext

Miten Azure Functions -toimintoja voidaan testata ja julkaista pilveen

Azure Functions tarjoaa tehokkaan tavan luoda ja ajaa palvelimettomia sovelluksia. Sen avulla kehittäjät voivat kirjoittaa pieniä koodipalasia, jotka suoritetaan pilvessä ilman, että heidän täytyy hallita itse palvelimia. Tässä kappaleessa tarkastellaan, miten luoda ja testata Azure Functions -toimintoja, jotka käsittelevät niin sanottuja jonoviestejä (queue triggers) ja BLOB-tallennusta (Blob Storage). Lisäksi käymme läpi, kuinka nämä toiminnot voidaan julkaista Azureen.

Kun Azure Functions -toiminto on määritelty, se voi vastaanottaa erilaisia syötteitä ja suorittaa halutun tehtävän sen mukaan. Esimerkiksi funktion voi laukaista viesti jonossa (queue trigger), jolloin toiminto suoritetaan aina, kun uusi viesti lisätään kyseiseen jonoon. Tämä mahdollistaa dynaamiset ja reaktiiviset työnkulut ilman tarvetta jatkuvasti toimiville palvelimille.

Yksi esimerkki on CheckGeneratorFunction, joka luo kuvia ja tallentaa ne BLOB-tallennukseen. Tämä toiminto voidaan käynnistää viestin avulla, joka lähetetään jonoon, kuten checksQueue. Toiminto käsittelee viestin ja tuottaa kuvan, joka tallennetaan joko paikallisesti tai pilvessä olevaan BLOB-säiliöön. Kuvan nimi on asetettu dynaamisesti nykyisen UTC-ajan mukaan, mikä estää tiedostojen nimien päällekkäisyyksiä. Tässä esimerkissä käytetään myös ImageSharp-kirjastoa kuvan luomiseen.

Jos ympäristömuuttuja "IS_LOCAL" on asetettu arvoon "true", kuva tallennetaan paikalliselle tiedostojärjestelmälle. Muussa tapauksessa kuva siirretään suoraan BLOB-säiliöön muistivirran (memory stream) avulla. Tätä varten tarvitaan BLOB-säiliöasiakas (BlobContainerClient), joka mahdollistaa yhteyden BLOB-tallennukseen.

On tärkeää huomata, että Azure Functions -toimintoihin liittyvät ympäristömuuttujat, kuten IS_LOCAL, voivat määritellä, kuinka tiedot käsitellään. Paikallisessa kehityksessä tallennus tapahtuu usein tiedostojärjestelmään, mutta pilvessä toiminto käyttää BLOB-säiliöitä.

Kun Azure Functions -toiminto on määritelty ja testattu paikallisesti, sen voi helposti siirtää pilveen. Tähän on useita tapoja, ja yksi yleinen vaihtoehto on käyttää Visual Studio 2022:n graafista käyttöliittymää (GUI). Tällä tavalla voidaan luoda uusi Azure Function App ja liittää se olemassa olevaan Azure-tiliin. Funktio voidaan määrittää ja julkaista suoraan Visual Studiossa, ja sen yhteyksiä voidaan hallita yksinkertaisesti eri konfiguraatioiden avulla.

Azure Functions tarjoaa joustavuutta ja skaalautuvuutta, mutta on myös tärkeää ymmärtää, kuinka testata ja vianmäärittää toimintoja kehityksessä ja siirryttäessä tuotantoon. Esimerkiksi jonoviestejä käsittelevien toimintojen testaaminen vaatii tarkkaa hallintaa siitä, milloin ja kuinka viestit käsitellään. Jos testausympäristössä käytetään paikallisia resursseja, kuten Azuritea (Azure Storage Emulator), voidaan testata tallennusprosesseja ja BLOB-kontteja ilman, että tarvitaan oikeaa pilviympäristöä.

Testauksen lisäksi on tärkeää pitää mielessä, että Azure Functions -toimintojen suorituksessa voi olla viiveitä ja virheitä, jotka johtuvat resurssien käytöstä, verkon ongelmista tai muista teknisistä tekijöistä. Tämän vuoksi on suositeltavaa lisätä virheenkäsittelylogiikka ja seurantamekanismit, jotka auttavat tunnistamaan mahdolliset ongelmat ajoissa.

Azure Functionsin käyttö voi tuoda merkittäviä etuja, kuten skaalautuvuuden ja kustannustehokkuuden. On kuitenkin huomioitava, että vaikka Azure Functions -alustan käyttö on suhteellisen yksinkertaista, sen täysi potentiaali avautuu vasta silloin, kun ymmärretään, kuinka eri palvelut kuten BLOB-tallennus, jonot ja ympäristömuuttujat toimivat yhdessä. Tämä tieto auttaa optimoimaan sovelluksia ja varmistamaan niiden sujuvan toiminnan myös tuotantoympäristössä.

Kuinka asentaa ja käyttää SQL Server -kehitysympäristöä Windowsissa ja Azure-alustalla

Täysimittaisen SQL Server -ympäristön asentaminen Windows-käyttöjärjestelmään edellyttää järjestelmällistä lähestymistapaa, jossa otetaan huomioon sekä ohjelmiston ominaisuudet että kehittäjän käyttötarpeet. Microsoft tarjoaa ilmaisen Developer Edition -version, joka sisältää kaikki täysversion ominaisuudet ilman tuotantokäyttöön liittyvää lisensointia. Asennusprosessi alkaa lataamalla Developer Edition Microsoftin virallisilta verkkosivuilta, jonka jälkeen asennusohjelma ohjaa käyttäjän mukautettuun asennukseen. Asennuksen aikana valitaan tarvittavat komponentit, kuten Database Engine Services, määritetään oletusinstanssi tai nimetty instanssi, ja konfiguroidaan tietoturva-asetukset, kuten sekatilan todennus (Mixed Authentication) ja vahva salasana sa-käyttäjälle.

SQL Server Management Studio (SSMS) toimii pääasiallisena käyttöliittymänä tietokantojen hallintaan ja kyselyiden suorittamiseen. Asennuksen jälkeen Management Tools -paketti ladataan erikseen, minkä jälkeen SSMS mahdollistaa yhteyden muodostamisen palvelimeen paikallisesti piste-merkinnällä (.) tai nimetyllä instanssilla (.\instanssin_nimi). Kun yhteys on muodostettu, voidaan SQL-tiedostoja avata ja suorittaa suoraan SSMS:ssä.

Esimerkkitietokannan, kuten Northwindin, luominen tapahtuu suorittamalla valmis SQL-skripti, joka on ladattavissa kirjaprojektin GitHub-repositorysta. Skripti avataan SSMS:ssä, suoritetaan, ja lopuksi voidaan tarkastella luotujen taulujen sisältöä, kuten Products-taulua. Koko prosessi osoittaa, kuinka kehitysympäristö voidaan luoda täysin paikallisesti ilman erillistä pilvi-infrastruktuuria.

Vaikka SSMS on tehokas työkalu Windows-ympäristössä, moderni kehitystyö hyödyntää usein kevyempiä, alustariippumattomia vaihtoehtoja. Visual Studio Code tarjoaa SQL Server -laajennuksen (ms-mssql.mssql), joka lisää käyttöliittymään erillisen näkymän tietokantayhteyksiä varten. Lisäksi Azure Data Studio (ADS) asentuu automaattisesti SSMS:n mukana ja tarjoaa kevyemmän, avoimen lähdekoodin vaihtoehdon SQL-tietokantojen hallintaan.

Niille, joilla ei ole Windows-laitetta tai jotka haluavat kehittää pilviympäristössä, Azure tarjoaa mahdollisuuden luoda SQL Database -instanssi. Azure-portaalissa luodaan ensin resurssiryhmä ja sen jälkeen uusi SQL-tietokanta, jonka yhteydessä määritetään palvelimen nimi, sijainti ja todennusmenetelmä. SQL-tietokannan palvelin saa yksilöllisen nimen, joka muodostaa osan julkisesta URL-osoitteesta. Tietoturva-asetuksissa määritetään esimerkiksi sallittujen IP-osoitteiden pääsy palvelimeen, ja oletusasetukset voidaan jättää suurelta osin voimaan.

Palvelimen konfiguroinnin jälkeen tietokannan laskentateho ja tallennustila valitaan, esimerkiksi Basic-taso, joka tarjoaa 2 Gt tallennustilaa kevyille kehitystarkoituksille. Lopuksi määritetään varmuuskopioinnin redundanssi ja valitaan julkinen päätepiste verkkoasetuksissa. Tietokannan luomisen jälkeen ADO.NET-yhteysmerkkijono voidaan kopioida ja säilyttää paikallisesti esimerkiksi muistiinpanosovelluksessa, jossa sen rakenne voidaan jäsentää helposti lisäämällä rivinvaihtoja puolipisteiden jälkeen.

On tärkeää huomioida, että SQL Serverin täysimittainen hyödyntäminen edellyttää sekä työkalujen tuntemusta että järjestelmän kokonaissuunnittelun ymmärrystä. Kehitysympäristön valinta—paikallinen vai pilvipohjainen—määrittelee pitkälti, millaisia työkaluja ja prosesseja kehittäjä käyttää. Sekä SSMS että Azure Data Studio tukevat samoja perustoimintoja, mutta kehittäjän omat preferenssit, projektin laajuus ja tiimin infrastruktuurivaatimukset vaikuttavat työkalun valintaan.

On myös keskeistä ymmärtää autentikointimenetelmien vaikutus tietoturvaan. Sekatilan todennus mahdollistaa sekä Windows- että SQL-kirjautumisen, mutta vaatii huolellista salasanojen hallintaa ja pääsyoikeuksien rajaamista. Lisäksi palomuurisäännöt ja IP-osoitteiden hallinta Azure-ympäristössä ovat kriittisiä komponentteja palvelimen suojaamisessa. Oletusasetusten käyttö kehitysympäristössä voi olla hyväksyttävää, mutta tuotantoon siirryttäessä niiden arviointi uudelleen on ehdottoman tärkeää.

Miten suojata salasanoja ja avaimia salauksen avulla turvallisesti?

Kun käsitellään salasanojen ja muiden arkaluonteisten tietojen suojaamista, perinteinen lähestymistapa on yksinkertainen: suolataan (salt) salasanat ja hashaamme ne. Tämä yksinkertainen periaate ei kuitenkaan ole riittävä, jos halutaan todella turvallista tietojen käsittelyä. Salasanan suolaaminen parantaa tietoturvaa, mutta on vain yksi osa laajempaa suojausmekanismia.

Salasanan suolaaminen alkaa siitä, että käyttäjältä pyydetään syöttämään salasana, joka yhdistetään suolaan ennen sen hajauttamista. Suola toimii tässä tapauksessa satunnaisena lisäyksenä, joka estää samanlaisten salasanojen tuottamista samanlaisiksi hajautusarvoiksi, vaikka ne olisivatkin samat. Kun käyttäjä kirjautuu seuraavan kerran sisään, järjestelmä tarkistaa suolan, yhdistää sen käyttäjän syöttämään salasanaan, hajauttaa tuloksen uudelleen ja vertaa sitä aiemmin tallennettuun hajautusarvoon. Jos ne ovat samat, tiedämme, että salasana on oikea.

Vaikka suolaaminen parantaa tietoturvaa merkittävästi, se ei ole riittävää, jos haluamme suojata tietomme täysin. On tärkeää käyttää lisämenetelmiä, kuten PBKDF2, bcrypt tai scrypt. Nämä menetelmät lisäävät merkittävästi salasanan murtamisen vaikeutta, mutta niiden selittäminen menee tämän kirjan aiheen ulkopuolelle.

Kun käsitellään salausavaimia ja alustusvektoreita (IV), tilanne muuttuu monimutkaisemmaksi. Avaimet ja IV:t ovat tavu-taulukoita, ja molemmat osapuolet, jotka haluavat vaihtaa salattuja tietoja, tarvitsevat nämä arvot. Tavu-taulukot voivat kuitenkin olla hankalia siirtää luotettavasti. Yksi luotettavimmista tavoista avaimen ja IV:n luomiseen on käyttää salasanasidonnaista avaimen johdannaisfunktiota, kuten PBKDF2:ta. Hyvä esimerkki on Rfc2898DeriveBytes-luokka, joka ottaa syötteenään salasanan, suolan, iteraatiomäärän ja hajautusalgoritmin (oletusarvoisesti SHA-1, mutta sitä ei enää suositella). Tämä luokka generoi avaimet ja IV:t, joiden turvallisuus paranee sitä mukaa, kun iteraatioiden määrä kasvaa. Mitä enemmän iteraatioita, sitä vaikeampaa on murtaa salaus.

Itse asiassa IV:n tulisi olla satunnaisesti luotu joka kerta ja siirrettävä salaamattomana viestissä, sillä sen ei tarvitse olla salainen. Hyvänä käytäntönä voidaan pitää, että suolan koko olisi vähintään 8 tavua ja iteraatioiden määrä niin suuri, että salauksen avaimen ja IV:n luominen vie noin 100 millisekuntia kohdekoneessa. Tämä arvo kasvaa ajan myötä, sillä prosessoreiden teho paranee.

Salaus ja salauksen purku voidaan suorittaa useilla eri algoritmeilla .NET-ympäristössä. Vanhemmassa .NET Frameworkissa jotkut algoritmit on toteutettu käyttöjärjestelmässä, ja niiden nimiin on lisätty CryptoServiceProvider tai Cng. Uudemmassa .NET:ssä kaikki algoritmit toteutetaan käyttöjärjestelmässä, ja jos käyttöjärjestelmän algoritmit on sertifioitu Federal Information Processing Standards (FIPS) -standardeilla, .NET käyttää niitä sen sijaan, että toteuttaisi algoritmin itse. Tämä tarkoittaa, että kun käyttöjärjestelmän tietoturvahaavoittuvuudet korjataan, .NET-sovellukset hyötyvät korjauksista välittömästi. Tämä kuitenkin rajoittaa .NET-sovellusten mahdollisuuksia käyttää vain niitä ominaisuuksia, joita käyttöjärjestelmä tukee.

Jos halutaan kirjoittaa koodi, joka salaa ja purkaa tietoja, on tärkeää valita oikea salausalgoritmi. Symmetriset algoritmit, kuten AES, ovat yleisesti suositeltuja. AES on peräisin Rijndael-algoritmista, joka on yksi parhaista salausmenetelmistä. Asymmetriset algoritmit, kuten RSA, puolestaan mahdollistavat salauksen, mutta niiden kapasiteetti on rajoitetumpi – ne voivat käsitellä vain pieniä tietomääriä kerralla.

AES:ää voidaan käyttää tehokkaasti suurten tietomäärien salaamiseen käyttämällä CryptoStream-luokkaa, kun taas RSA voi käsitellä vain pieniä tavuja kerrallaan. Jos sinun on käytettävä RSA:ta jossain, älä sekoita sitä DSA:han (Digital Signature Algorithm), joka ei voi salata tietoja vaan ainoastaan luoda ja tarkistaa digitaalisia allekirjoituksia.

Erityisesti salauksessa on tärkeää huomioida valittavan algoritmin vahvuus ja suorituskyky. AES on paras valinta symmetriseksi salaukseksi, kun taas RSA on optimaalinen asymmetriseksi salaukseksi. Näiden valinta riippuu aina tietoturvavaatimuksista ja suorituskykyvaatimuksista.

Endtext

Miten tehdä terveellisiä herkkuruokia ja nauttia niistä kohtuudella?
Kuinka suuri teknologia ja tekijänoikeuslainsäädäntö kohtaavat tekoälyn aikakaudella?
Miksi matemaattiset käsitteet, kuten raja-arvot ja jatkuvuus, ovat keskeisiä ymmärtää laskettaessa monimutkaisempia ongelmia?