‘Arhitektuur’ sildiga artiklid

Küllaltki tüüpiliseks peetakse rakenduse vigade logimist. Proovitakse kasutada Aspect Oriented Programmingu võtteid, et saavutada see võimalikult lihtsalt, kuid siiski kui palju on kasu logist, mis kõik vead kirja paneb?

Paljudel kordadel kui vea kirja paneme, on rakendame ka mehhanisme, et olukorda taastada kasutaja jaoks. Seetõttu ei tohiks meid väga huvitada need veateated. Ise pole sattunud väga logisid lugema, võib-olla on see algaja õnn vms. Põhimõtteliselt peaksime kirja panema need juhtumid, mida me ei oota, mitte need, mis on vuugitäiteks. Näiteks kui proovime minna lehele ASP.NET MVC rakenduses, mille kontrollerit ei leita, siis võime saada küllaltki tüüpilise vea. Kas kellegi viga viitamisel peaks tootma meie logi? Arvatavasti oleks piisavalt kena näidata kasutajale kurba sõnumit, et seda lehte pole ja lõpetada sellega.

Loe edasi »

Pea iga rakendus vajab andmete salvestamist, eriti nö andmepõhised rakendused. Seetõttu tuleb meil siduda rakendused andmebaasiga ning võimalusi selleks on mitmeid.

Küllaltki tüüpiline on alguses kasutada andmebaasi lähedast mudelit. Ehitada ise andmete vahetuskiht ja teha DataAccess objekte. Sellise lähenemisega kaasneb hulgaliselt andmekihi kirjutamist, tihti on see lausa 80% projekti mahust ning pärast kolmandat korda tundub, et pidevalt on loodud sama koodi. Oren Eini (Ayende Rahien) ühes ettekandeski ütles, et see on lahendatud probleem ning sellele vastu vaielda väga mõistlik pole.

Loe edasi »

Enne jooksmist tasub paelad kinni siduda, siiani on see hea praktika olnud. Samalaadselt peame rakenduse loomisel objektid omavahel siduma. Nagu saapapaelu saab mitut erinevat moodi siduda, saab ka objekte.

Kõige lihtsam viis on see, et üks objekt loob teise ja kutsub välja meetodi, kuid seal tekkivad tihtipeale hunnik probleeme. Meil pole võimalik testides seotud objekti võimalik välja vahetada ning see viib tavaliselt välja olukorrani, kus ühe testi käivitamiseks peame hulgaliselt seadistama.

Loe edasi »

Modernse tarkvara all mõtlen ma peamiselt veebipõhiseid klient – server rakendusi. Neid me kohtame peamiselt teenustena. See muidugi ei tähenda, et töölaua rakendused ei ole modernsed ning selles seerias käsitletud teemasid saab hästi ka nende puhul rakendada.

Seeria sisaldab peamiselt arhitektuurilisi lähenemisi, kuid ka mõnda praktikat. Näited ja viited tulevad peamiselt .NET maailmast, sest sellega olen kõige rohkem kursis, kuid üritan anda ülevaateid, kuidas neid Ruby, PHP ja Java mõttemudelis kasutada. Kui teil endal on kogemusi selles osas, siis jagage neid julgelt kommentaarides.

Praeguseks on teemad, millest kirutama hakkan järgmised: andmebaaside haldamine; Object Relational Mapperi kasutamine; Active Record mustri kasutamine, Data Transfer Objectide teisendamine; valideerimine; Dependency Injection; logimine; Model-View-Controller; integratsioon. Kui soovite veel mõnel teemal kirjatükki saada, siis jätke kommentaaridesse teade, millest huvitatud olete.

Üks populaarsemaid kasutajaliides loomise mustreid veebirakenduste juures on Model-View-Controller ehk lühidalt MVC. Seda kohtame nii PHP, .NET, Ruby ja Java maailmas, kuid mõnes neist võib lähenemisnurk olla veidi erinev.

Liigume edasi nüüd mustri lahkamise juurde:

• Model –  Selle all mõeldakse tihtipeale ärimudelit, mis pole kõige valem, kuid parem oleks mõelda vaatemudelit. Põhjus on selleks lihtne – vaates võivad olla spetsiifilised väärtused kuvamise jaoks olla (n: mõne elemendi CSS klass) ning need ei peaks olema ärimudeli küljes. Lisaks võiks see sarnaneda võimalikult Data Transfer Objectile, mille teisendab Controller ärimudelist. Sel puhul ei peaks muretsema selle üle, et kui mingit meetodit või atribuuti kutsuda ei hakata andmebaasi vms kallale minema.
• View – Peamiselt HTML vaade kus seotakse andmed malliga. Teisisõnu lõpptulemus, mida kasutaja näeb.
• Controller – Küsib andmehoidlast vastava ärimudeli, käivitab vastavad äriprotsessid ja teisendab tulemuse vaatemudeliks ning kuvab vaate.

Loe edasi »

Läbi aegade on mudelid aidanud meil probleeme lahendada. Enne Bohri mudelit oli Rutherfordi mudel ja kuubi mudel – kõik kirjeldasid sama asja, kuid erinevatest vaatenurkadest ja täpsusastmest ning sellest tulenevalt oli võimalik teooriaid nende peale luua, mis üks hetk võisid vähem vajalikuks muutuda.

Bohri mudel võib olla vägagi täpne, kuid vahel meile piisab ka kuubi mudelist. Teisisõnu mudelid ei pea täielikult peegeldama reaalsust. Võtame mudelisse need osad reaalsusest, mis rajatava süsteemi jaoks olulised on ja ka neid vääname enda nägemise järgi abstraktsioonidega. Näiteks rakuehituse uurimisel pole meile aatomite maailm väga oluline.

Loe edasi »

Mõni aeg tagasi sai vesteldud kirja teel Patrick Smacchiaga NDependist. Seda rakendust olen varemgi uurinud, kuid prooviversioonis CQL-i päringuid kasutada ei ole võimalik, mis tundub olevat üheks väga heaks abimeheks. Võrreldes Microsoft FxCopi või Gendramega, siis sealne viis reegleid lisada on tunduvalt parem.

Tundub, et see rakendus võiks olla olemas ettevõtetes, kus ehitatakse .NET platvormil ja hinnatakse koodi kvaliteeti. Nüüd aga väikese vestluse juurde.

Loe edasi »

Viimasel ajal on tekkinud tunne, et rakendused, mis pakuvad peamiselt välja nimekirju andmetest ja võimaldavad neid ka sorteerida ja filtreerida on laristamine. Need rakendused lähevad tellijale tihtipeale kõvasti maksma ja hea on kui nad enda investeeringu tagasi teenivad.

Tunnet kinnitab ka CRUD tüüpi nõuete kaardistamine nii kasutajalugude kui ka kasutuslugude puhul. Proovige mõni CRUD kasutajalugu kirjutada: Projektijuhina soovin hallata projekte, et … projekte juhtida/meeskonna tööd paremaks muuta/jne. Need ei tundunud väga head äriväärtused olevat, vähemalt ma ei näe kasu sellest, et projektide nimekirja sorteerimisel ja filtreerimisel paraneks meeskonna töö vms. Pigem näeksin selliseid kasutajalugusid: Projektijuhina soovin näha nimekirja problemaatilistest projektidest koos soovitusega kuidas reageerida, et projektide õnnestumise protsent paraneks.

Loe edasi »

Esimese GeekDinneri teemaks oli xDUF ehk Big Design Up Front (BDUF), Enough/Little Design Up Front ja No Design Up Front. Vestlus oli igati huvitav ning neile, kes ei jõudnud tulla, väikene tutvustus seisukohtadest.

Esimene äärmus, mille vaatluse alla võtame on BDUF. See parktika on tulnud otse ehitusest – kõigepealt tuleb plaanid valmis teha ja siis hakata reaalselt ehitama. Tundub esmapilgul loogiline samm, kuid tarkvara on siiski pehme ja lihtsamini muudetav kui maja, mida ehitatakse.  Teine problemaatiline koht selle vaate puhul on, et peaksime suutma võtta kõike arvesse võtta ja seda siiani inimesed teha ei suuda.

Mittetäielikkuse printsiip:
Ei ole võimalik kõike arvesse võtta, kõike määratleda, kõike põhjendada.
[Lorents, “Süsteemse käsitluse alused”, lk 26]

Loe edasi »

Eelmisest veidi parem valideerimise variant tundub olevat kapseldada reeglid ühte eraldiseisvasse klassi. See on hästi kooskõlas ka Single Responibility Principlega.

public class PersonValidator : AbstractValidator<Person>
{
    public PersonValidator()
    {
        RuleFor(x => x.FirstName).NotNull().And.Length(1, 25);
        RuleFor(x => x.LastName).NotNull().And.Length(1, 25);
        RuleFor(x => x.PersonalCode).NotNull().And.Matches("[0-9]{11}");
        RuleFor(x => x.DateOfBirth).NotNull().And.LessThan(DateTime.Today);
        RuleFor(x => x.Age).NotNull().And.GreaterThan(1).And.LessThan(120);
    }
}

Loe edasi »