Selle versiooni suuremad edasiminekud on veebi arendamise osas. Nüüd on võimalik MVC ja tavalise ASP.NET-i peal genereerida vajaminevat koodi ja kiirelt parandada vigasid. Lisaks on seal osas ka navigeerimist paremaks tehtud. Veebiarendus hakkab ka nüüd R#5 jaoks olema esmaklassiline kodanik.

Märkimisväärne uuendus on ka koodi analüüsis – võimalik on otsida koodi struktuurilisi/mustrilisi vigasid ehk halbu lõhnu. See on suurepärane töövahend meeskonna koodi ühtlustamise osas ning uute koolitamisel.

Kui Visual Studio 2010 oskab kenasid UML diagramme luua, siis R#5 seevastu näitab lihtsamalt, kuidas väärtused või meetodi väljakutsed aset leiavad. See kiirendab oluliselt koodist arusaamist (juhul kui pole üks suur kauss spagette).

Väiksemate väärtuste hulka võiksid kuuluda koodiviited (bookmark) ja ka NUniti integratsioon. Rohkemat infot leiate R# uuenduste nimekirjast.

Kellel suurem huvi koodi kirjutamise produktiivsuse tõstmise katsetamiseks on, võiksid heita ka pilgu peale Telerik JustCodeile, kuigi sellel on vähem võimalusi. Oleks tore ka kuulda, mis teile uues R# meele järgi on ja mis puudujääke on.

Loe veel sarnasel teemal:

1. ReSharper 4 Viimase kuu olen kasutanud R# 4 öiseid versioone (nightly build),...
2. Töö kiirendamine ReSharper’i ja klaviatuuriga Paljude arendajate jaoks on pärast Re# kasutamist võimatu kasutada Visual...
3. ReSharper mallid Nagu mõni aeg tagasi sai lubatud, siis panen R# mallid...

Peamiselt on meil vaja uus kood kokku kompileerida, lisada talle uus versiooni number, andmebaasi skeem uuendada ja andmete kohandada. Väga palju polegi. Automatiseerimiseks sobivad lihtsad skriptid: kõige algupärasem variant oleks teha konsooli skript, kuid selleks peame väga hästi tundma iga kasutatava rakenduse parameetrite süntaksit.

Java maailmast on tuntud võlujoogid Ant, Maven ning Ruby tulekuga Raven ja Buildr. Ant oli esimesi selliseid, millega kokku puutusin ning üleminekul .NET-i peale oli loomulik valik NAnt. Nüüdseks on alternatiive tekkinud MSBuild-i ja PSake (PowerShell) näol. Siiski on mind väga kütkestanud Ruby keelelised võimalused ning Rake-i kasutamine .NET asjade jaoks ei ole probleemne.

Nende kõigi eesmärgiks on luua skript, mis pakendab rakenduse kenasti kokku ühe nupu vajutusega. Kuna olen veidi väsinud XML-ist, siis liigun vaikselt Rake poole. Varajasemalt sai kirjutatud, miks see mulle nii väga meeldib ning vastava skripti võite leida GitHubist ja vajamineva koodi sellest kataloogist. See ei ole seal täiuslik, vaid eksperiment, mida tuleks edasi viia. Kellel on huvi mind selles vallas aida, siis andke teada.

Lisaks eelnevale rakenduse pakendamisel on tihti suur soov näha, kas testid läbivad ning analüüsida koodi kvaliteeti. Välistatud pole ka API dokumenteerimine. Kui nii palju tööd on juba tehtud, siis poleks enam keeruline pideva integratsiooni server seadistada ning veelgi rohkem kasu lõigata. Vastavaid servereid on palju: CruiseControl.NET (uued mallid 1.5 CTP jaoks leiate GitHub-ist), CruiseControl, Hudson, PHPUnderControl, TeamCity…

Kogemusest soovitan kohe algusest peale hoida keskkonna poolsed seaded eraldi kohas ning neid vastavalt ka sisse laadida. Teine hea soovitus on jagada skriptid loogilisteks tükkideks, sest nii on võimalik vastavad skriptid teha lihtsamini uuestikasutatavateks. Suure tõenäosusega loome rohkem kui ühe veebipõhise vms rakenduse. Ajapikku on mul tekkinud NAnti skriptid, mida saab suhteliselt lihtsalt ümber majandada ning neid võite leida järgnevast GitHub-i kataloogist. See võib lihtsustada nii mõnegi tööriistaga sidumise. Kui kellelgi veel sarnaseid skripte kuskil peidus on, siis oleks tore, kui avaldaksite need.

Väärtuslikku lisa võib leida Paul Duvalli, Steve Matyase ja Andrew Gloveri raamatust “Continuous Integration: Improving Software Quality and Reducing Risk”. See raamat räägib kogu protsessi elementidest küllaltki detailselt.

Kui kõik vajalik on seadistatud, siis tuleb hoiduda järgneva tigeda grupeeringu eest: Phyllis, Agnes ja Gladys. Ühe nupu vajutusega rakenduse pakendamine ja paigaldamine hoiab kõvasti aega kokku ja on stressivabam. Tasub vähemalt proovimist.

Loe veel sarnasel teemal:

1. Modernne tarkvara loomine VII: Logimine või blogimine? Küllaltki tüüpiliseks peetakse rakenduse vigade logimist. Proovitakse kasutada Aspect Oriented...
2. Modernne tarkvara loomine IV: Andmete kühveldamine Pea iga rakendus vajab andmete salvestamist, eriti nö andmepõhised rakendused....
3. Modernne tarkvara loomine V: Mitu kasutajakontot sul on? Väga lihtne küsimus teile: mitu kasutajakontot sul kokku on? Ma...

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.

Mõnigi ettevõtte on otsustanud mingi ajahetk, et tuleb luua enda raamistik andmete vahetamiseks ning kulutanud selle arendamiseks palju aega. Tõesti on tore, kui on võim raamistiku üle, kuid kas see siiski tasub ära? Tuletades enda töökäigu algust meelde, siis tõesti sai paar rakendust tehtud nii, et andmekiht sai ehitatud ise. Pärast Java Persistence API ja NHibernateiga tutvumist ei näinud enam põhjusi tagasiminekuks. NHibernate-i kasutatakse .NET maastikul päris palju ning tehniline tugi on küllaltki suur – kirjuta ainult enda probleem Googlesse ja vastus ei ole kauge tulema.

NHibernate on Object Relational Mapper (ORM), mille ülesandeks on siduda andmebaas objektmudeliga. Selle tulemusena saame peamiselt tegeleda objektidega ja see tundub täiesti mõistlik lähenemine. NHibernate on algselt ületoodud java poolsest raamistikust Hibernate, mis tundub olevat sealsel maastikul vägagi populaarne; PHP-s olen kokku puutunud Doctrine ja Propeli nimelise raamistikuga; .NET maailmas on võimalik kasutada ka Microsofti enda toodangut Entity Framework, mille esimene versioon sai kommuuni poolt tugeva kriitika, kuid vaadates tema tulevikku, siis tundub see paranevat ja võib olla on ka alternatiiviks tulevaste projektide puhul.

Peamiselt kasutatakse ORM-e rikkaliku objektmudeli puhul ning paljud veebirakendused on väga lihtsa ülesehitusega, millest tulenevalt on see veidi ülepaisutatud (siiski kasutaksin pigem ORM-i, kui hakkaksin ise tegelema andmebaasi kihi loomisega). Lihtsamate mudelite puhul on alternatiiviks Active Record muster, kus äriobjekt sisaldab ka päringuid ja salvestamist, kustutamist. Selle mustri headeks näideteks on Ruby on Railsi ActiveRecord ja ka NHibernate-i peale loodud Castle ActiveRecord ning ka SubSonic.

Raamistik, mille osas ma head seisukohta ei oska võtta on LINQ to SQL, mis XML kaardistamise puhul on päris kasutatav. Natukene oli probleeme POCO saavutamiseks, kuid see ei olnud väga valus.

Väikeseks vahepalaks küsiks neilt, kes on oma ettevõttes loonud mõne sarnase asja või arendanud mõnda andmekihi raamistikku, miks need väljapakutud variandi ei ole sobilikud? Olen kuulnud, et üks pühjus on see, et genereeritud SQL päringud ei ole väga head, kuid arvesse võttes keskmise arendaja tugevust selles, siis panustaksin ikkagi siinpuhul esimesele poolele. Teine põhjus võiks olla kiiruse probleemid, kuid see on lahendatav riistvara juurde ostmisega, sest arendajad on kallimad kui riistvara ning pole ka mingisugust garantiid, et tulevane raamistik kiire on. Kolmandaks põhjuseks võiks tuua, et XML on paha, kuid Ruby on Railsi ActiveRecord minu teadmist mööda ei kasutagi mingit seadistust ja NHibernate’i puhul saab kasutada FluentNHibernate’i, mis suures osas võib seadistuse automaatselt ära teha.

Ise olen Oren Einiga nõus, et see on lahendatud probleem. Võime küll luua alternatiivseid lähenemisnurki, kuid ilma suurema põhjuseta ei pole küll mõistlik oma andmekihi raamistikku looma hakata. Võite vürtsitada seda postitust kirjutades kommentaaridesse enda sõjasaagasid.

Loe veel sarnasel teemal:

1. Modernne tarkvara loomine VII: Logimine või blogimine? Küllaltki tüüpiliseks peetakse rakenduse vigade logimist. Proovitakse kasutada Aspect Oriented...
2. Modernne tarkvara loomine III: Andmebaasi versioonimine Koodi versioonime on küllaltki elementaarne nähtus (jah, mõned tõesti ei...
3. Modernne tarkvara loomine VI: Uuendused võluväel Tarkvara arendamine on pidev tegevus; pidevalt ilmuvad uuendused ja vigade...

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.

Tekkis väike kokkupuude Joomla!-ga ning ka seal on välja hõigatud, et kasutatakse MVC-d. Kõik tundus mõnus kuni reaalselt koodi tuli kirjutama hakata, sest sellega pandi mu arusaam mustrist kahtluse alla. Modeli tähendab seal hübriidi vaatemudelist ja andmehoidlast. Siinkohal võiksime apelleerida ActiveRecordi mustrile, et päringud ongi mudeliga koos, kuid siiski tegemist on vaatemudeliga ning reaalne ärimudel võiks olla sealne JTable objekt.

Järgmine oluline samm komponendi loomisel on Controlleri loomine, mis oli vägagi sarnane mu enda arusaamaga. Siiski väheke häiris mind see, et entry point tuli ise luua, mis võiks tähendada reaalselt FrontControllerit. Veidi mõistlikum viis oleks kasutada viidete reegleid (routing) Controllerite loomisel. Õnneks seal saab kasutada ühte ja sama faili erinevate komponentide tegemisel ning ise ei ole vaja väga leiutada.

Controlleri üks ülesanne on valida välja õige vaade (View). Vaated on tavaliselt HTML mallid, kuid sel puhul oli PHP fail ning vajas veel toimetamist. ASP.NET maailmas oleks samaväärne Code Behind fail, mis kahjuks oli tihtipeale prügikasti rolliga. Vaade laadis omakorda sisse reaalse malli (Template, Layout), mis kandis vaate tegelikke ülesandeid.

Segadust oli palju mustri väänamisega, kuid ei saa öelda, et see halvasti tehtud oleks, sest ma ei mõista veel kõiki tagamaid, mis otsuste langetamisel arvesse võeti. Soovitan teistel, kes loovad mõnda sarnaseloomulist raamistikku, siis kasutada mustreid nii nagu nad üldtuntuses on. Mustrite ülesanne on vähendada probleemi kirjeldamist ja lahendamist.

Loodetavasti mu kogemus aitab teil lihtsamini tutvust teha Joomla!-ga.

Loe veel sarnasel teemal:

1. Modernselt tarkvara loomine I: Sissejuhatus Modernse tarkvara all mõtlen ma peamiselt veebipõhiseid klient – server...
2. Appi, mu rakenduses on mitu mudelit! Läbi aegade on mudelid aidanud meil probleeme lahendada. Enne Bohri...
3. Modernselt tarkvara loomine II: Seotud paelad Enne jooksmist tasub paelad kinni siduda, siiani on see hea...

Kuna 1.5 ei tule kohe välja (praeguste andmete järgi oktoobris), siis jagan teiega vahepealseid tulemusi, et saaksite tagasisidet anda, kuidas muuta kvaliteedi kontrollimine tõhusamaks.

Vahepealsed uuendused:

• Administraatori mallid said valmis.
• Projektide filtreerimine täiustus:
  Automaatselt jagatakse projektid 3 gruppi: aktiivsed, mitteaktiivsed (projektid, mida pole 7 päeva builditud) ja kinni pandud.
  Kuna mõnedel inimestel on 300+ projekti nagu tuli välja CC.NET mailinglistis, siis nime järgi otsimine tõhustab jõudsasti projektide haldamist.
• Projektivaates kollased projektid on need, mida hetkel ehitatakse.
• Muudatuste ajaloo mall sai kokku viidud uue kujundusega.
• Muudatuste malli värvikriteerium sai muudetud: alla 20 muudatuse on korras; 20-40 annab märku, et peaks midagi ette võtma; üle 40 on problemaatiline. See põhineb printsiibil, et integreerida tuleks tihedalt, kuid numbrite osas praegu pole erilist analüüsi tehtud, seega soovi korral võite pakkuda paremaid numbreid enda reaalsusest.
• Abi sektsioon sai lisatud: viide lokaalsele CC.NET dokumentatsioonile ja kiirklahvide nimeloend.
• Uue vaate pakendamine sai ka paremaks muudetud.

Edasised plaanid:

• Integreerida CC.NET 1.5-ga
• Projekti graafikute mall valmis teha
• Raporteid juurde lisada

Kes soovib seda praegu enda pideva integratsiooni serverile lisada, siis saate selle alla laadida siit.

Head kvaliteedi parandamist.

Loe veel sarnasel teemal:

1. CruiseControl.NET uus ja ilus nägu Täna on mul hea uudis CruiseControl.NET kasutajatele. Kunagi alustasin selle...
2. Cruise Control.NET uus nägu Viimasel ajal olen parajalt aega kulutanud Cruise Control.NET raportite lehe...
3. Vähem päringuid ASP.NET-ga .NET 3.5 Service Pack 1-ga tuli ASP.NET lehtedele juurde võimalus...

Mida see juurde annab?

Üks suuri puudusi CCNET-is oli see, et projekti viimase buildi raporti juurde jõudmiseks tuli meeletult hiirega navigeerida. Palju lihtsam on vajutada näiteks 1, L.

• D – Dashboard
• 1…9 – Sektsioonid (avalehel projektid)
• Q – avab kõik plokid
• W – sulgeb kõik plokid
• E – avab kõik vigade ja hoiatustega plokid
• R – peidab/kuvab kõik vigadega plokid (punased)
• G – peidab/kuvab kõik korras plokid (rohelised)
• Y – peidab/kuvab kõik hoiatusega plokid (kollased)
• Z – eelmine build
• X – järgmine build
• L – viimane build
• B – avab/sulgeb viimasete buildide nimekirja menüüs

Teine probleem seisnes selles, et raske oli kiirelt vaadates näha, millised on problemaatilised kohad. Võtsin siinkohal kasutusse testimisest meelepärase lahendus: roheline on korras, kollast tuleks üle vaadata ning punasega tegeleda. Lisaks kiirklahvidele on neid lihtne kiirelt filtreerida. Loodan, et teilegi see meeldib ja uutel inimestel on lihtsam alustada.

Programmeerijad tihtipeale vabandavad, et pole disainerid ning nende rakendused võivad halva näoga olla, kuid mina nii ei arva ja usun, et teile meeldib see välimus rohkem.

Esmajärjekorras võtsin käsile need raportid, mida ise kasutan, sest nende puhul on mul võimalik lihtsalt näha, millised need välja näevad. Praegu töötavad raportid on järgnevad:

• Modifications
• Errors and Warnings
• Tests (NUnit)
  Kasutades testide nimetamisel alakriipse, siis raportis on need asendatud tühikutega, mis teeb lugemise tunduvalt meeldivamaks.
• Design Analysis (FxCop)
• Code Coverage (NCover 1.58, NCoverExplorer)
• Code Duplication (Simian)

Mida veel oodata?

• Administraatori liides
• Projekti graafikud
• Raportid (NDepend, FitNesse, Gendarme, MBUnit, MSTest…)
• Midagi huvitavat kindlasti veel…

Kes soovib saada teavitust järgmise uuenduse kohta, siis võib saata mulle kirja selle kohta. Hea oleks kui vigade ja ettepanekute korral jätaksite jälje kas kommentaaridesse või saadaksite need kirjaga.

Kuidas paigaldada?

Mõistlik oleks anda teile veel väike juhend, kuidas paigaldada seda ning viide, kust selle alla saab tõmmata. Paigalduse poole pealt on soovitav kasutada CCNET 1.4.4.83 versiooni ning teha sealsest webdashboardist koopia. Seejärel allatõmmatud paki sisu sinna lahti pakkida (teil tuleb võib-olla ka teha väikeseid seadistusi ka dashboard.config failis).

CruiseControl.NET uus välimus

Loe veel sarnasel teemal:

1. Cruise Control.NET uus nägu Viimasel ajal olen parajalt aega kulutanud Cruise Control.NET raportite lehe...
2. CruiseControl.NET uue välimuse tulevik Uue välimuse arendamine on tegusalt läinud ning sain ka soojasid...
3. Vähem päringuid ASP.NET-ga .NET 3.5 Service Pack 1-ga tuli ASP.NET lehtedele juurde võimalus...

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.

Kuidas NDepend kasulik on tarkvaraarenduses?

NDepend aitab koguda reaalseid fakte koodibaasist. Tihtipeale on tarkvara arendamine kahjustatud kuulujuttude poolt milline see on. Näiteks arendaja võib väita, et suur osa hiljutisest tehtud tööst on kaetud testide poolt ja üleüldine kvaliteet on nõuetega vastavuses. NDependiga on võimalik koheselt kontrollida selliseid väiteid.

Kuna koodibaas on iga tarkvaraarendusfirma ja toote keskne vara, siis kasulikkus peaks olema silmaga nähtav. Kontrollida töövahendiga, mis koodibaasi kvaliteedis, sidususes ja arengus reaalselt toimub, on uus võimalus meeskonna jaoks. Ilma sarnase töövahendita nagu NDepend on võimalik saada ähmane idee toimuvast kasutades hulgaliselt koodiülevaateid, mis on kulukad võrreldes alternatiiviga. NDepend toob muudab suhtlust meeskonnas: enam ei pea küsima “mis toimub”, vaid saab fokuseerida “miks see juhtub nii” (leida põhjus, mitte arutleda tagajärgedest).

Millised eelised on NDependi kasutada sarnaste töövahenditega turul, näiteks Visual Studio 2010 Architect versiooniga?

Siiani tean, et NDepend on unikaalne töövahend ja me ei saa neid teistega võrrelda. NDepend läheb tunduvalt sügavamale kui Reflector, kui tegemist on kvaliteedi ja struktuuriga, kuid NDepend kasutab Reflectorit, kui on vaja dekompileerida koodi.

Visual Studio 2010 Architect tõepoolest sisaldab mõningaid kattuvusi NDependiga. See liigutus Microsofti poolt näitab, et meil on selliseid töövahendeid vaja ning oleme õnnelikud, et oleme .NET maailmas esimesed sellise tootega. VSTS2010 ja NDependi vaheline kattuvus on piiratud, peamiselt see sisaldab arhitektuuri / sidususe vaadet. VSTS2010 tuleb suurepärase arhitektuuri valideerimise ja UML diagrammide loomise võimalusega, kuid NDependil on ikka võimalus kontrollida 82 erinevat koodi mõõdikut, võrrelda erinevad versioone koodibaasist, defineerida reegleid ja konventsioone CQL abil ja teha keerulisemaid sidususe analüüse (transitive closure).

Kas NDepend toetab meetrikuid parimate praktikate osas nagu SOLID printsiibid, spartalik programmeerimine, CRAP mõõdikut?

Jah, NDepend tuleb 150 erineva eeldefineeritud konventsiooniga, mida võib koheselt ise kasutama hakata. Lisaks on võimalik endal defineerida reegleid.

* Spartaliku programmeerimise (Spartan Programming) täpsemaid CQL päringuid võib leida Patrick Smacchia ajaveebist.

* CRAP (Change Risk Analysis and Predictions) mõõdik on defineeritud järgnevalt:
CRAP(m) = complexity(m)^2 * (1 – coverage(m) / 100)^3 + complexity(m), kus complexity on meetodi keerukus (cyclomatic complexity) ja covarege on meetodi kaetavus testidega. Mida suurem väärtus on, seda raskem on seda koodihulka hallata. Java platvormil on olemas Crap4j

Kui keeruline on alustada NDependiga? Kas NDepend pakub mingisugust lahendust probleemidele, mida ta avastab ja kuidas parandada koodi kvaliteeti?

Lisame võimalikult palju dokumentatsiooni juba rakendusse ning pakume ka veebilehel hulgaliselt dokumentatsiooni, seal hulgas on ka 20 lühikest õppevideot, kuidas rakendust kasutada.

* Abi alustamiseks leiab NDependi kodulehe sektsioonist Getting started ja mõõdikute osas võib lugeda dokumentatsiooni või võtta appi väljatrükitav seletusleht (PDF).

Kas NDepend-i on võimalik saada avatud lähtekoodiga projektide jaoks soodsamalt?

Jah, kui soovite kasutada NDependi OSS projekti jaoks, siis võtke meiega ühendust.

Loe veel sarnasel teemal:

1. Arendajate vestlus – Raido Tonts Alustasime Saiku Kaizenis tarkvaraarenduse teemaliste vestluste sarja. Eesmärk on tutvustada...
2. NHibernate 2.0 Mõni aeg tagasi tuli välja NHibernate 2.0, mida on võimalik...
3. Visual Studio 2010 Täna teatas Microsoft, et järgmine Visual Studio versioon on 2010...

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);
    }
}

Siinkohal oleks mõistlik luua enda baasklass ning liides:

public interface IValidator<TEntity>
{
    IValidationResults Validate(TEntity entity);
}

public abstract class BaseValidator<TEntity> : AbstractValidator<TEntity>, IValidator<TEntity>
{
    public IValidationResults Validate(TEntity entity)
    {
        //...
    }
}

public class PersonValidator : BaseValidator<Person>
{
    public PersonValidator()
    {
        //...
    }
}

Edaspidi võime registreerida ServiceLocatoris IValidator<Person> liidesele vastavaks PersonValidatori ning enne salvestamist samalaadselt valideerimine läbi viia.

Sellise lahendusega tekkib ka mõningasi keerukohti, mis võivad tahta lahendamist. Kuna kasutusel on generic tüübid, siis on veidi raskem lisada seda NHibernate‘ salvestamise eelseks sündmuseks. Selleks tuleb meil eelnevalt kokku panna tüüp IValidator<TEntity>, kus TEntity on määratud konkreetse tüübiga. Alternatiivne lahendus on kasutada seda lihtsalt IRepository<TEntity>.Save(TEntity entity) meetodis.

Erinevalt atribuutidest pole meil väga võimalusi luua konventsioone, mistõttu tuleb meil osades kohtades rohkem koodi kirjutada või leida alternatiivseid lahendusi (reeglitest välja lugeda atribuudiga seotud nõuded).

Hea külg selle juures on see, et saame kasutada raamistikke, kus on äriobjektid defineeritud, sest me ei pea lisama atribuute neile, vaid kirjutame valideerimise reeglitega klassi juurde.

Raamistikud:

• FluentValidation for .NET

Loe veel sarnasel teemal:

1. Valideerimine atribuutidega Atribuutide kasutamine valideerimiseks tundub paljude jaoks hea mõte olevat. Seda...
2. Vaesed inimesed Andekad inimesed on tihtipeale tööl vaesed. Nende annet ei lubata...
3. Kuss, kompilaator! Avatud lähtekoodiga projekte uurides jäi mulle silma üks C# konstruktsioon,...

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; }
}

Esimene muret tekitav koht on see, et klass Person on seotud konkreetse valideerimise raamistiku attribuutidega. Paljusid see ilmselt ei häiri. Kuna neid raamistikke on palju, siis raamistiku ümber vahetamine hiljem võib täiesti tõenäoline olla (kui algne valik ei olnud hea ja mõnel teisel raamistikul on paremad võimalused) ning palju õnne selle tegemisel.

Teine probleem seisneb selles, et kasutades mõne raamistiku äriklasse, siis ei ole võimalik neile valideerimise reegleid lisada. See tähendab seda, et luues väärtuse tüüpi (Value Object)  klassid, mida mitmete süsteemide puhul kasutada saaks (Money, Quantity, GeographicBoundary jne), puuduvad valideerimise reeglid.

Kolmas probleem tekkib sellega, et äriloogikas on tihti keerukamad reeglid, mida atribuudid täita ei suuda ning seetõttu tuleb lisada näiteks Validate meetod juurde. See teeb klassi disaini imelikumaks.

Atribuutidega on võimalik ka häid asju korda saata. Näiteks võime Required atribuudiga elementidele lisada automaatselt andmebaasi loomise skripti NOT NULL märke FluentNHibernate abiga.

public class Persistence : PersistenceModel
{
    public Persistence()
    {
        Conventions.ForAttribute<RequiredAttribute>((attribute, property) =>
        {
            if (property.ParentIsRequired)
                property.SetAttribute("not-null", "true");
        });
    }
}

[MSDN Magazine: Conventions over configuration]

Sarnaselt võime luua TextBoxid, mille pikkus on paika pandud pikkuse reegli järgi või luua DropDownListi väärtustega, mis jäävad vastavasse vahemikku. Siinkohal tuleb ainult ideedel lennata lasta ja neid realiseerida.

Siiani oleme tegelenud ainult reeglite deklareerimisega, siis tuleks ka need mingil moel jõustada. Lahendus selleks on luua teenus IValidationService:

public interface IValidationService
{
    IValidationResults Validate<T>(T entity);
    IValidationResults Validate(Type entityType, object entity);
    IValidationResults Validate(object entity);
}

Seda võime kasutada enne salvestamist andmehoidlas või registreerida salvestamise eelseks sündmuseks, kus ebakorrektsete andmete puhul visatakse viga. Mõlema puhul oleks mõistlik ServiceLocatori käest konkreetne realiseering küsida ja käivitada mõni neist meetoditest. Siinkohal tasub silmas pidada ka seda, et NHibernate annab tagasi proxy klasse ning valideerimine võib seetõttu vahele jääda kui valideeritava objekti tüüpi kaasa ei anna.

Tagasi ärimudeli atribuutidega solkimise juurde tulles, siis alternatiivne lahendus oleks kasutada neid transpordi objektidel ning äriolemid realiseerida selliselt, et neid poleks võimalik ebakorrektsesse seisu viia.

Raamistikud:

.NET

• Enterprise Library Validation Application Block
• NHibernate Validator
• xVal

Java

• OVal
• JaValid

Loe veel sarnasel teemal:

1. Valideerimine ilusate liidestega Eelmisest veidi parem valideerimise variant tundub olevat kapseldada reeglid ühte...
2. Võtame kaalust alla Peter Paul Rubensile meeldisid lopsakad naised ja ta maalis neist...
3. Vaesed inimesed Andekad inimesed on tihtipeale tööl vaesed. Nende annet ei lubata...

Esimene probleem, mida võib presentatsioonidel näha on see, et ei julgeta/viitsita Visual Studiot ümber kujundada (visuaalselt), samas ei kasutata neid nuppe ka väga. Produktiivsuse esimene reegel on fokuseerimine ühele tegevusele/asjale. Senikaua kuni sodi (aknad ja nupud) on ees, seni ei saa häirimatult fookust suunata näiteks koodi kirjutamisele ja ka väga väikese pinna peal on halb tööd teha. Kes arvab, et Solution View või Properties vaadet on vaja koodi kirjutamisel kogu aeg lahti hoida, see eksib ilmselgelt (või palun seletage mulle kuidas on hea koodi kirjutada ja passida näiteks Solution View‘d Text Editori asemel).

Kui piisavalt ruumi teha, siis on mõistlik võtta ette ka koodi kirjatüüp ja koodi värvimine. Tumedama tausta peal tundub kuidagi mõnusam koodi kirjutada ja suurema kirjaga näeb ka seda paremini. Värvitoonide vahetamine võib tuua tegelikult ka veel kasu mõtlemises. Näiteks mul on klassitüüp ja liidese tüüp erinevat värvi. Küllaltki lihtsalt näen klassile peale vaadates, milline tüüp on tugevamini seotud. Värvigammade kohta on Scott Hanselmanil päris hea kokkuvõte.

Küllaltki palju kasu võiks leida Fullscreenist, kui see nupp ei oleks üleval nii silma torkav. See ei pruugi kõigil nii olla, kuid mul on =D

Samas ruumieelist ka väga oluliselt ei saa (peamiselt taskbari võrra).

Järgmisena tuleks välja valida, millise tulevärgiga edasi minna, sest Visual Studio sisseehitatud funktsionaalsus on veel veidi puudlik (Microsoft ka ei jõua kõike ülihästi teha): ReSharper, CodeRush, Visual Assist X. Ise kasutan ReSharperit, kuid CodeRush koos Refactor Pro’ga on ka igati hea valik. Viimast ei ole ise proovinud, seega oleks tore selle kohta mõni kommentaar saada.

Valiku tegemisel ja nende õppimist aitavad järgnevad videod:
Becoming a Jedi I
Becoming a Jedi II
Becoming a Jedi III
DNR TV: Mark Miller on CodeRush with Refactor!

Kellele on mureks, et kõvakettale kirjutatakse mingeid temp faile, siis nad peaksid ümber mõtlema veidi. Ka SVN kirjutab faile projekti kausta. Lisaks on ka kõvaketas odavam kui arendaja töö ning Jeff Atwood on kirjutanud kunagi sellise hea programmi Clean Sources Plus, mis puhastab projekti kataloogi etteantud mustri järgi failidest.
Tunduvalt nutusem oleks, kui ReSharper ei kirjutaks neid sinna, sest sellisel juhul tuleks kõik see info mällu uuesti genereerida.

Pärast ümber struktureerimist visuaalselt pole võimalik hiirega väga palju enam majandada ja produktiivsuse tulevärgist midagi kätte saamiseks tuleb hakata õppima kiirklahve. Tihtipeale on raske kõikide akende kiirklahve meeles pidada, siis tasub need süstematiseerida kuidagi. Näiteks mul on alumisel real olevad aknad kõik ALT + Number kiirklahviga ning tagasi koodi peale saan ESC nupuga.

ALT klahviga on võimalik pääseda programmi menüüsse ja sealt edasi saab tähtede abiga menüüs ringi käia. Näiteks ALT, R, U, N käivitab kõik testid ReSharperi puhul (hmm… päris huvitav sõna tuleb kokku, pole varem sellise pilguga vaadanudki).

Väike vahekokkuvõte:
1. Puhast visuaalselt sodist.
2. Vaheta värvigammat.
3. Vali ja kasuta produktiivust tõstvat töövahendit
4. Õpi kiirklahvid

Ajapikku tunneb ikka mõnesid puudujääke, mida saab väiksemate vahenditega leevendada. Näiteks GhostDoc dokumenteerimiseks, CodeRush-i kasutajale TestDriven.Net jne. Nimekirja igasugustest kasulikest tööriistadest leiab siit (tundub, et Scott Hanselmanile meeldib kokkuvõtteid teha).

Teine hea koht kuhu aega veidi investeerida on mallid. Nende abiga saab nii mõndagi korda saata. CodeRush-il on päris tõhusad viisid, kuidas kiirelt koodi kirjutada (DNR TV videost näeb seda kenasti). Kellel ReSharperi malle vaja läheb, siis võib leida mu omasid sealt.

Edasi veel tasub minna sellega, et Visual Studio ei ole ainuke koht, kust annab produktiivsust tõsta. Ka windowsi teistest rakendustest saab veidi rohkem välja pigistada ning sealt edasi võiks mõelda e-posti majandamisele (Inbox Zero: tekst, pilt ja heli) ja töö planeerimisele jms.

Loe veel sarnasel teemal:

1. ReSharper 4 Viimase kuu olen kasutanud R# 4 öiseid versioone (nightly build),...
2. Produktiivsusest: Vangistus tööl Jalutad tööle ning mõtteis mõlgub vaid küsimus: “Miks sean samme...
3. Töö kiirendamine ReSharper’i ja klaviatuuriga Paljude arendajate jaoks on pärast Re# kasutamist võimatu kasutada Visual...