Antud nipp on kindlasti kogenumatele EF-i (Entity Framework) ja SQL serveri andmebaasi protseduure (stored procedure ehk SP) kasutavatele arendajatele teada. Mina näpin EF-i niimoodi vahelduva eduga ja vahest satub mõne orka otsa lausa mitu korda. See on üks nendest oradest. See on ka selles mõttes ora, et normaalne ja loogiline (loe: oodatud) käitumine oleks teistsugune.

Oletame, et mul on üks andmebaasi protseduur (SP), millel on üks sisend ja kaks väljund parameetrit (kusjuures väljundparameetrite arv antud juhul ei oma mingit tähtsust).

   1: CREATE PROCEDURE [dbo].[Test_Sp] 

   2:     @someval INT,

   3:     @ValueOut INT OUTPUT,

   4:     @ValueOut2 VARCHAR(50) OUTPUT

   5: AS

   6: BEGIN

   7:     SET NOCOUNT ON;

   8:     

   9:     SELECT  @ValueOut = COUNT(*), @ValueOut2 = 'misiganes' 

  10:     FROM [MingiTabel]

  11:     

  12:     SELECT * FROM [MingiTabel]

  13: END

Seejärel loon omale EF-i mudeli ning lisan SP antud mudelisse, et oleks strongly typed lähenemine (kood) protseduuri väljakutsumiseks.

Kõik on ilus ja toimib suurepäraselt. Kirjutan ka koodi, mis antud protseduuri välja kutsub ja antud juhul lihtsalt kirjutab konsoolile.

Nüüd antud koodi oodatav väljund lugedes oleks, et “[MingiTabel] ridade arv“, “misiganes”. Päriselt on aga väljundiks:

Nüüd on aeg veidi pead kratsida ja mõelda, mida see EF õige mõtleb. Kui te SQL Profileriga vaataksite, siis te näete et OUTPUT väärtused ilusti tagastatakse. Objekti parameetritesse need aga ei jõua.

Asi nimelt selles, et antud protseduur tagastab kaks asja – select lause tulemuse (loetelu mingitest objektidest) ja need kaks väljund parameetrit. EF eeldab, et oma täie mõistuse juures olles kõigepealt soovite loetelu mälusse saada ja alles seejärel on teil huvi nende väljud parameetrite vastu. ObjectResult<T> tundub olevat käitumise poolest sarnane olevus IQueryable<T> –ga, et andmed laetakse siis kui antud tulemusega soovitakse midagi peale hakata (n-ö lazy loading ehk laisk laadimine) ja alles seejärel on muutuvad väljundparameetrid kättesaadavaks.

Tip! Seega väljundparameetrite kättesaamiseks peate materialiseerima (kui nii võib kirjutada) oma loetelu ja siis on väljund parameetrite väärtused olemas. Toimiv kood näeb välja järgmine:

Ning tulemus.

Edu!

Ma olen viimasel ajal mõtisklenud, et millal on kasulik kasutada var võtmesõna C# –i koodis ja millal see võib hoopiski segadust tekitada koodi lugejas. Minu mõtted ei pruugi olla mitte kuidagi originaalsed siin, kuigi ma loodan, et natukenegi on. Ei ole hetkel kuskilt juhendeid selle jaoks lugenud.

Praktikas olen ma jõudnud järgnevatele lähenemistele:

• Kasuta var –i juhul kui lood mõnda kompleks objekti nagu FileInfo, SqlConnection, DateTime …

Näide:

   1: var stopper = new Stopwatch();

Koodirida on loetav ja mõnusam muuta. Teistpidi oleks täitsa tüütu.

• Ära kasuta var –i lihttüüpide puhul nagu int, string, double, …
• Ära kasuta var-i objekti omaduse või meetodi kutsumisel tagastustüübi defineerimisel, kui tegu on lihttüübiga

Näide:

   1: var sourceLocation = ConfigurationManager.AppSettings["SourceLocation"];

   2: var targetLocation = ConfigurationManager.AppSettings["TargetLocation"];

   3: var sizeCounterInMB = 0.0000;

   4: var allFiles = Directory.GetFiles(sourceLocation, "*.*", SearchOption.AllDirectories);

   5: var file = allFiles[0];

   6: var targetFullPath = file.Replace(sourceLocation, targetLocation);

   7: var fileInfo = new FileInfo(targetFullPath);

   8: var directory = fileInfo.DirectoryName; 

Kas sa tõesti saad aru lihtsalt peale vaadates, mis tüüpi asi sulle tagasi antakse? Oletame et sa ei tea ConfigurationManager.AppSetting indexerist midagi või teistest objektidest ning nende omadustest.

Palju paremini loetav on sama kood järgneval kujul:

   1: string sourceLocation = ConfigurationManager.AppSettings["SourceLocation"];

   2: string targetLocation = ConfigurationManager.AppSettings["TargetLocation"];

   3: double sizeCounterInMB = 0.0000;

   4: string[] allFiles = Directory.GetFiles(sourceLocation, "*.*", SearchOption.AllDirectories);

   5: string file = allFiles[0];

   6: string targetFullPath = file.Replace(sourceLocation, targetLocation);

   7: var fileInfo = new FileInfo(targetFullPath);

   8: string directory = fileInfo.DirectoryName; 

Ka koodi kirjutamisel saab peale vaadates paremini aru mis olevusega tegu on ning on lihtsam manipuleerida.

Ma hetkel mõtisklen, kas keerukamate objektide puhul on kasulikum tagastustüübi defineerimisel kasutada var–i või mitte. Mugavam kindlasti, aga loetavam?

Mis te arvate ja missuguseid reegleid kasutate var-i juures?

Eneta portaali üks viimaseid uuendusi on tehnoloogia raamatute ja ajakirjade saitide lisandumine. Igaühel on võimalus kirjutada arvamus ja soovitus mõne lemmik tehnoloogia raamatu või ajakirja kohta. Juhul kui raamat/ajakiri juba eksisteerib, saab sellele juurde lisada oma väärtusliku kommentaari.

Eelmisel nädalal andsin ka mina sinna oma panuse lisades arvamuse raamatule “The Art of Unit Testing with Examples in .NET”, mis on kirjutatud Roy Osherove –i poolt.

Soovitan seda raamatut kõikidele ühik testide (unit test) kirjutajatele.

Edu!

Olen varasemalt kirjutanud, kuidas XmlReader–st lugeda nii, et tulemus salvestataks otse XmlWriter-sse. Kuna XmlReader ja XmlWriteriga seotud API ei ole alati kõige selgem ja lihtsalt mõistetav, siis kirjutaks veel ühest nipist, mida tavapäraselt võib vaja minna.

Kuidas kontrollida, kas XmlReaderisse loetud XML on tühi (ei sisalda sisu) või mitte. Vahest võib see kasulik olla. Näiteks, kui andmebaasipäring tagastab XML-i ja te soovite seda lugeda otse XmlReader abil ning antud päring võib tagastada tühja stringi, kui pole ühtegi andmerida XML-na tagastada.

Järgnev illustreeriv koodisnipet on abiks sellisel juhul.

   1: using (var xmlReader = XmlReader.Create(*))

   2: {

   3:     if (xmlReader.MoveToContent() != XmlNodeType.None)

   4:     {

   5:         var result = XElement.Load(xmlReader);

   6:         return result;                        

   7:     }

   8:     return new XElement("empty");

   9: }

Kontrollides xmlreader.MoveToContent() != XmlNodeType.None, saame teada, kas XmlReaderis on sisu ja kui on, siis loeme selle sisu Linq to XML –i XElement objekti. Kui te prooviksite lugeda XElement.Load(xmlReader) ja selles xmlReaderis on tühi string, siis visataks teile viga, et tegu on invalid xml –ga. Tühi string pole korrektne XML. Antud juhul viga ei teki ja me tagaastame hoopiski XElement objekti milles on element “empty”.

Edu!

Mitmeid kordi olen otsinud, kuidas saaks kirjutada XmlReaderist otse XmlWriterisse ja ma pean tunnistama, et .NET-i  API ei ole väga intuitiivne selles osas. Igakord kui seda vaja, siis ma otsin seda uuesti.

Kõlab nagu väärtuslik postitus mulle ja võibolla ka teistele.

Stsenaarium

Soovin lugeda kettalt sisse XML–i faili ja otse väljundisse kirjutada. Väljundiks võib olla ASP.NET –i output stream või muu koht. Igatahes soovitakse faili mälusse laadimist vältida.

Lahendus

   1: using (var reader = XmlReader.Create("sisend.xml"))

   2: using (var writer = XmlWriter.Create(HttpContext.Current.Response.Output))

   3: {

   4:     while (reader.Read())

   5:     {

   6:         writer.WriteNode(reader, false);

   7:     }

   8: }

Kes oleks arvanud, et see nii lihtne on!

Edu!

.NET –i ja C# maailmas on kaks arendamisreeglite kogu, mida võetakse kui de facto standardina aluseks oma arendamisreeglite ja kokkulepete dokumendi/kogumiku loomisel.

Üheks neist on Microsofti poolt uuendatav “Design Guidelines for developing class libraries”.

Teiseks on vast kujunenud IDesign’i “The IDesign C# Coding Standard for development guidelines and best practices”.

Vaieldamatult põhjalikumad raamatud antud teemadel on “Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries” v1 ja v2. Ise olen läbi lugenud v1 ja see oli vägagi õpetlik ja nauditav. Põhimõtteid, mida sealt lugesin rakendan ma oma igapäeva arenduses siiamaani ja nad toimivad (on muutnud koodi paremini hallatavaks, organiseeritumaks ning ühtlasemaks).

• Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries v1
• Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries v2

SQL –i maailmas olen ma leidnud ka mõned viited, mis võivad kandideerida alusena:

• Best Practices , Design and Development guidelines for Microsoft SQL Server

Muide http://code.msdn.microsoft.com –s olev SQL Examples on üldse väga nutikas ja põnev koht kasulike näidetega.

Võibolla teate mõnda paremat .NET –i, C# –i või SQL maailmas? Palun jagage kommentaarina siia postituse juurde.

Kirjutasin kunagi ammu C# –i seeriat ja seal hulgas tutvustasin @ väljendit. Mõtlesin, et kui ma juba nii hilja üleval olen ning avastasin, et üks nüans on jäänud selle puhul mainimata, siis kirjutaks kiirelt ühe postituse ka ära.

Nimelt on @ –l veel üks lahe omadus.

Kui lisate @ stringi algusesse, siis saate ilma stringe liitmata vabalt teksti kirjutada (k.a. reavahetustega) kuni stringi lõpu märgini (“). Näide on parem, kui minu sõnastus sel kellaajal.

Näide 1:

public static readonly string BookApprovedEmail = @"<html><body><p>Tere {0},</p>
                                                  <p>Teie raamatu '{1}' arvamus kinnitati</p>
                                                  <p>Administraatori selgitus: {2}</p>
                                                  <p>Tervitustega,<br/>ENETA meeskond</p></body></html>";

Näide 2:

var queryString = @"<Where><And>
                        <Eq><FieldRef Name='RealAuthor' LookupId='True' /><Value Type='User'>{0}</Value></Eq>
                        <Eq><FieldRef Name='ContentType' /><Value Type='Text'>{1}</Value></Eq>
                        </And></Where>";

Teeb antud juhul stringi veidi loetavamaks. Need ei pruugi olla eeskujulikud näited, aga illustreerivad kasutust ikkagi ;)

Edu!