Kategooria ‘Arhitektuur’ 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 »

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 »

Atribuutide kasutamine valideerimiseks tundub paljude jaoks hea mõte olevat. Seda väidet kinnitab selliste raamistikkude rohkesus. Ei saa vastu vaielda, et see on üks lihtsamaid viise, kuid tasuks ka vaadata alternatiive enne kasutamist, sest seegi pole ilma tumeda pooleta.

public class Person
{
    public int Id { get; private set; }

    [Required, Length(Max = 25)]
    public string FirstName { get; set; }

    [Required, Length(Max = 25)]
    public string LastName { get; set; }

    [Required, Pattern("[0-9]{11}")]
    public string PersonalCode { get; set; }

    [Required, PastDate]
    public DateTime DateOfBirth { get; set; }

    [Required, Between(Min = 1, Max = 120)]
    public int Age { get; set; }
}

Loe edasi »

Kas olete kuulnud hullumeelsest, kes päise päeva ajal süütas laterna ja kõndis mööda turgu, karjudes: “Ma otsin jumalat! Ma otsin jumalat!” [---] Hullumeelne tormas inimeste sekka, puuris neid pilguga. “Kus on jumal?” hüüdis ta. “Ma tahan teile seda öelda! Meie tapsime ta – teie ja mina! Me kõik oleme tema mõrvarid!”
Friedrich Nietzsche, Rõõmus teadus

Ka tarkvara arendajad otsisid enda jumalat (Monty Python‘lik Püha Graali otsing), kuid leiud ei olnud kiiduväärt. Sel jumalal on mitu nime, ehk olete teiegi neid kuulnud: Manager, Global, God, System, Driver jne. See on jumala muster – tema teab, kuidas maailma luua ja kõiki tarkuseteri, kuid need terad on mürgised. Hea, et tapsime ta, haletsust ta ei vaja.
Loe edasi »