Alles over .NET, Sitecore en websites.

.NET Features: question mark

Door Luuk1983 op donderdag 23 juni 2011 09:03 - Reacties (11)
Categorie: Programmeren, Views: 4.099

Als .NET-programmeur merk ik regelmatig dat andere programmeurs niet op de hoogte zijn van sommige handige en slimme features in het .NET framework die het programmeren een stuk makkelijker kunnen maken. Soms zijn deze features verstopt, of soms zijn ze pas nieuw, maar handig zijn ze altijd. Dit is deel 4 van een serie met kleine voorbeelden van features die je als .NET-programmeur (met name in C#) mogelijk nog niet kent. Deze keer: het vraagteken in C#.

Met het vraagteken kan je in C# een hoop dingen doen. Ik zal een aantal voorbeelden geven van toepassingen van het vraagteken.

Ten eerste kan je het vraagteken gebruiken om objecten die dat standaard niet zijn nullable te maken. Nullable houdt in dat er een null waarde toegekend kan worden. De toepassing hiervan is redelijk beperkt omdat objecten die afstammen van de Object class al nullable zijn, maar dingen zoals een int of bool zijn dat standaard niet.

C#:
1
2
3
4
//This doesn't work
int aNotNullableInt = null;
//This is OK
int? aNullableInt = null;


Je kan nu met .HasValue en .Value controleren of het object null is of niet en wat de waarde dan is.

C#:
1
2
3
4
5
6
7
8
9
object foo;
//The long version
if (aNullableInt.HasValue)
    foo = DoSomething(aNullableInt.Value);
else
    foo = DoSomething(-1);

//The short version that does the same thing
object foo = (aNullableInt.HasValue) ? DoSomething(aNullableInt.Value) : DoSomething(-1);


Als de conditie voor het vraagteken true is zal de code direct achter het vraagteken uitgevoerd worden. Als de conditie false is zal de code direct achter de dubbele punt uitgevoerd worden.

Al laatste is er een constructie met een dubbel vraagteken. Waar de constructie hierboven bedoeld is om middels een conditie optie A of B te laten uitvoeren, is de dubbele vraagteken constructie bedoeld om een alternatieve optie te geven in het geval dat een object null is:

C#:
1
2
3
4
5
6
7
8
9
//This is the long version
object newObject;
if (foo != null)
    newObject = foo;
else
    newObject = new object();

//This is the short version that does the same thing
object newObject = foo ?? new object();


In het geval dat 'foo' null is zal de waarde achter de ?? toegekend worden aan newObject.

Wederom hoop ik dat jullie er wat aan hebben. En wederom zijn suggesties altijd welkom.

.NET Features: Object Initializer

Door Luuk1983 op woensdag 22 juni 2011 11:20 - Reacties (11)
Categorie: Programmeren, Views: 2.344

Als .NET-programmeur merk ik regelmatig dat andere programmeurs niet op de hoogte zijn van sommige handige en slimme features in het .NET framework die het programmeren een stuk makkelijker kunnen maken. Soms zijn deze features verstopt, of soms zijn ze pas nieuw, maar handig zijn ze altijd. Dit is deel 3 van een serie met kleine voorbeelden van features die je als .NET-programmeur (met name in C#) mogelijk nog niet kent. Deze keer: Object initializers in C#.

Ik zie nog veel programmeurs hun classes en bijbehorende properties op de volgende manier declareren:

C#:
1
2
3
var foo = new Foo();
foo.ABoolean = true;
foo.AnIntegerValue = 1;


Dit is natuurlijk niet fout, maar het kan ook anders. Je kan het aanmaken van het object combineren met het zetten van de waardes. Dit heeft als voordeel dat je code (mogelijk) beter leesbaar wordt. Zeker als er maar weinig properties gezet hoeven te worden kan de object initialisatie plus het zetten van de properties op één regel.

C#:
1
var foo = new Foo {ABoolean = true, AnIntegerValue = 1};


Naar mijn mening verhoogt dit de leesbaarheid van de code. De functionaliteit is toegevoegd vanaf C#3.0 en is te gebruiken vanaf .NET3.5.

.NET Features: auto properties

Door Luuk1983 op dinsdag 21 juni 2011 14:44 - Reacties (9)
Categorie: Programmeren, Views: 2.505

Als .NET-programmeur merk ik regelmatig dat andere programmeurs niet op de hoogte zijn van sommige handige en slimme features in het .NET framework die het programmeren een stuk makkelijker kunnen maken. Soms zijn deze features verstopt, of soms zijn ze pas nieuw, maar handig zijn ze altijd. Dit is deel 2 van een serie met kleine voorbeelden van features die je als .NET-programmeur (met name in C#) mogelijk nog niet kent. Deze keer: auto properties in C#.

In het algemeen is het goed gebruik dat als je variabelen wilt ontsluiten gebruik te maken van public properties (naast functions natuurlijk) en geen public variabelen. Het was altijd veel werk om publieke properties te maken, omdat je dan altijd een achterliggende private variabele moest declareren om de waarde in vast te houden. Hoewel je met de refactor optie van Visual Studio niet alles helemaal zelf hoefde uit te typen, was het toch omslachtig.

Dit hoeft sinds .NET3.5/Visual Studio 2008 niet meer. Dit geldt overigens alleen voor 'simpele' properties waar je alleen een waarde aan wil kunnen toekennen en uitlezen. Als je meer dan dat wilt, dan gaat onderstaand verhaal niet op.

Voorheen moest je properties zo declareren:

C#:
1
2
3
4
5
6
7
8
9
10
public class Foo
{
    private int _anIntegerValue;

    public int AnIntegerValue
    {
        get { return _anIntegerValue; }
        set { _anIntegerValue = value; }
    }
}


Sinds .NET3.5/Visual Studio 2008 kan het veel korter:

C#:
1
2
3
4
public class Foo
{
    public int AnIntegerValue { get; set; }
}


Je hoeft niet perse meer een achterliggende private variabele aan te maken, dat gebeurt automatisch.

Overigens kan je de get en set nog steeds andere access-modifiers geven:

C#:
1
2
3
4
public class Foo
{
    public int AnIntegerValue { get; private set; }
}


(dank CyCloneNL voor de toevoeging)

Je mag niet alleen de get of de set expliciet implementeren en de ander impliciet. Dit kan dus niet:

C#:
1
2
3
4
5
6
7
8
9
10
public class Foo
{
    private int _anIntegerValue;

    public int AnIntegerValue
    {
        get;
        set { _anIntegerValue = value; }
    }
}



Maar nogmaals: dit verhaal geldt alleen voor 'simpele' properties, als je meer wilt dan een waarde opslaan en ophalen, dan heb je meer nodig dan bovenstaand verhaal.

Hopelijk hebben jullie er wat aan! Suggesties zijn altijd welkom.

.NET features: Optional Parameters

Door Luuk1983 op maandag 20 juni 2011 08:36 - Reacties (23)
Categorie: Programmeren, Views: 2.380

Als .NET-programmeur merk ik regelmatig dat andere programmeurs niet op de hoogte zijn van sommige handige en slimme features in het .NET framework die het programmeren een stuk makkelijker kunnen maken. Soms zijn deze features verstopt, of soms zijn ze pas nieuw, maar handig zijn ze altijd. Dit is deel 1 van een serie met kleine voorbeelden van features die je als .NET-programmeur (met name in C#) mogelijk nog niet kent. Deze keer: optional parameters in C#.

Optional Parameters zijn nieuw in .NET 4.0 voor C# en kunnen gebruikt worden om één functie met meerdere signatures te maken in plaats van meerdere overloaded functies. Deze functionaliteit is al langer beschikbaar in VB.NET. Een simpel voorbeeld van een paar overloaded functies:


C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public void DoSomething()
{
    DoSomething(false, false);
}

public void DoSomething(bool bool1)
{
    DoSomething(bool1, false);
}

public void DoSomething(bool bool1, bool bool2)
{
    //Here code that does something
}



In .NET 4.0 kan dit samengevoegd worden tot één functie door middel van optional parameters. Je geeft dan aan welke properties optioneel zijn, waarna je ze niet perse hoeft in te vullen. Let wel op dat de optionele parameters altijd achteraan moeten komen te staan.

Je maakt parameters optioneel door ze een default waarde te geven:


C#:
1
2
3
4
public void DoSomething(bool bool1 = false, bool bool2 = false)
{
    //Here code that does something
}



Op dit moment zijn de volgende aanroepen naar bovenstaande functie geldig:


C#:
1
2
3
DoSomething();
DoSomething(false);
DoSomething(false,false);



Zoals je ziet zijn de drie overloaded functies aan het begin van deze blog nu vervangen door één functie met optionele parameters. Er is echter ook nog een belangrijk voordeel aan het gebruik van optional parameters: je hoeft niet perse alle optionele parameters in te vullen. Zo kan je in bovenstaand voorbeeld er ook voor kiezen om alleen de tweede parameter in te vullen en de eerste de default waarde te laten behouden:


C#:
1
DoSomething(bool2: true);



bool1 zal in dit geval zijn default waarde van false behouden en wordt alleen bool2 expliciet ingevuld.

Ik hoop dat jullie er wat aan hebben, of mochten er mensen zijn die nog wat aanvullingen hebben, dan hoor ik het graag.

[C#] Error na Response.Redirect

Door Luuk1983 op maandag 9 november 2009 12:24 - Reacties (12)
Categorie: Programmeren, Views: 3.183

Soms kan je tijdens het programmeren van die problemen tegen waarvan je denkt: Wtf is DIT nou weer?!?!?!?! Hele eenvoudige commando's die je heel regelmatig gebruikt geven een fout, terwijl je er eigenlijk heel weinig fout aan kan doen. Zo kwam ik laatst een fout tegen bij het gebruik van Response.Redirect().

Als er 1 functie is die ik vaak gebruik dan is het Response.Redirect(). Wat het doet mag duidelijk wezen: je Redirect van de huidige pagina naar een nieuwe pagina, bijvoorbeeld

C#:
1
Response.Redirect ("pagina.aspx");


Hoeveel kan je hier fout aan doen, right? Maar toch kreeg is een error, namelijk een 'thread aborted' exception.

Allereerst even de situatie in het kort. We hebben een object aangemaakt waarmee je met de volgende code een melding of een error kan toevoegen:

C#:
1
2
Website.AddError("Het ging fout");
Website.AddInfo("Het opslaan is met succes voltooid");


Deze meldingen worden als collectie in een sessie gestopt en bij de volgende Request (dus na een reload) worden deze sessies uitgelezen, verwijderd uit de sessie en weergegeven op de website. Dit zorgt voor een consistente manier van meldingen geven.
Ik heb de volgende code (uiteraard heel erg versimpeld) gemaakt:

C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
try
{
//Do wat dingen hier
DoeWat();

//Dingen zijn met succes afgerond
Website.AddInfo("Alle dingen zijn met succes afgerond");
Response.Redirect("TerugNaarMenu.aspx");
}
catch (Exception ex)
{
Website.AddError("Er is iets fout gegaan: "+ex.Message);
}


Als ik bovenstaande code uitvoerde werd 'DoeWat()' met succes afgerond, werd op het scherm de melding 'Alle dingen zijn met succes afgerond' weergegeven en er werd geredirect naar TerugNaarMenu.aspx. Echter, er kwam ook de melding te staan 'Er is iets fout gegaan: Thread abort exception".

Wat blijkt nu: Response.Redirect veroorzaakt STANDAARD een ThreadAbortException en blijkbaar wordt die gebruikt om de redirect mogelijk te maken. Deze exception wordt door het framework afgevangen en zal dus nooit een servererror op je scherm geven. Normaal merk je daar niks van, maar omdat in bovenstaande code de errors in een session gestopt worden komt deze later toch weer naar boven. In zekere zin was dit dus niet 'fout', maar standaard gedrag waar je normaal gesproken niets van ziet.

Er zijn uiteraard 2 manieren op dit op te lossen:
- De Response.Redirect uit de try, catch loop halen.
- De ThreadAbortException afvangen.

Ik heb voor dat laatste gekozen:

C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
try
{
//Do wat dingen hier
DoeWat();

//Dingen zijn met succes afgerond
Website.AddInfo("Alle dingen zijn met succes afgerond");
Response.Redirect("TerugNaarMenu.aspx");
}
catch (ThreadAbortException ex)
{ }
catch (Exception ex)
{
Website.AddError("Er is iets fout gegaan: "+ex.Message);
}