undvika hårdkodning

du kan ju skapa en klass HostTypes med en get metod som är static?

Det är enkelt ordnat med enum :birp

public enum HostTypes
{
    Database,
    XML
}

voigtann1 skrev:

du kan ju skapa en klass HostTypes med en get metod som är static?

Ahh, fiffigt! Tack! :bire

frequz skrev:

Det är enkelt ordnat med enum

Enums har jag inte jobbat med förrut men de verkar användarvänliga och trevliga! :) Men visst skulle väl det kräva att jag strukturerar om databasen till att lagra int istället för string?

doggelito skrev:

frequz skrev:

Det är enkelt ordnat med enum

Enums har jag inte jobbat med förrut men de verkar användarvänliga och trevliga! :) Men visst skulle väl det kräva att jag strukturerar om databasen till att lagra int istället för string?

Nja, int är det bästa men om det förstör db upplägget i övrigt kan du bara lägra siffrorna i nvarchar fältet bara som det är nu o casta i jämförelsen...och lägga in ett värde per HostType i enuym oxå... blir inte lika rent längre, så då kanske poängen går förlorad...

if(Convert.ToInt32(HostType) == (int)HostTypes.Database)
     ...

public enum HostTypes
{
    Database = 1,
    XML = 2
}

Mm, precis som du skriver så känns det som om poängen går förlorad då.
Men det är bra att veta tills nästa gång (eller om jag väljer att strukturera om redan nu)!
Dock vet jag inte om jag riktigt gillar idén med att lagra sånna här typer av värden som int i databasen. Det blir hopplöst då att gå in i databasen och titta i tabellerna, man kan inte tyda nånting, bara en massa siffror som inte säger nånting!

hmm tänker bara lite högt nu.. borde man inte kunna serialisera ner en enum o spara i ett fält i db och sen återskapa den igen...?

doggelito skrev:

Mm, precis som du skriver så känns det som om poängen går förlorad då.
Men det är bra att veta tills nästa gång (eller om jag väljer att strukturera om redan nu)!
Dock vet jag inte om jag riktigt gillar idén med att lagra sånna här typer av värden som int i databasen. Det blir hopplöst då att gå in i databasen och titta i tabellerna, man kan inte tyda nånting, bara en massa siffror som inte säger nånting!

Databasen används väl egentligen inte som någon slags presentation?
Jag tycker du skall köra på integers i databasen.

Lyssna på Nickemannen :)

Nickemannen skrev:

Databasen används väl egentligen inte som någon slags presentation?

Kloka ord! :D
Det är just under utvecklingen som jag vill kunna se vad som hänt i databasen, inte när siten rullat i månader/år. Men det kanske man kan vänja sig ifrån! :)

freguz skrev:

hmm tänker bara lite högt nu.. borde man inte kunna serialisera ner en enum o spara i ett fält i db och sen återskapa den igen...?

Ja, det finns en behändig parsemetod i Enum-klassen...

public enum Stuff { Foo, Bar, Baz; }
...
Stuff thing = Stuff.Foo;
string str = thing.ToString();
Stuff sameThing = [URL=http://msdn2.microsoft.com/en-us/library/system.enum.parse.aspx]Enum.Parse[/URL](typeof(Stuff), str);
// sameThing == thing == Stuff.Foo
Stuff bar = Enum.Parse(typeof(Stuff), "BAR", true);
// bar == Stuff.Bar

Nu har jag stuvat om i databasen och lagrar integers istället! :)
Men det blev ändå inte som jag tänkt mig! :q
Kör denna enum nu:

public enum HostTypes
{
    DataBase = 1,
    Xml
}

Men då säger den rackarns debuggern att:
Cannot implicitly convert type 'HostTypes' to 'int'.
Måste jag typomvandla min hosttype varje gång jag använder den så att det blir:

if(HostType == (int)HostTypes.DataBase)
     ...

Eller?
Det är ju bara snäppet bättre än vad jag hade från början! :(

Eller har jag missat nått?

Smartare är väl att typomvandla en gång för alla, och då en int till enumtypen, istället för tvärtom:

HostTypes ht = (HostTypes)LäsIntVärdeFrånDatabasen();
if (ht == HostTypes.DataBase) ...

Jag lägger min näsa iblöt lite..

Det spelar ingen som helst roll rent kodmässigt om du använder dig av int eller strängar i databasen. Man kan enkelt få tillbaka sin enum utifrån en sträng med hjälp av Enum.Parse() metoden.

Helt klart är att databasen oftas inte är ett presentationslager utan endast datakälla och den bör optimeras utifrån det. Det finns dock tillfällen då man väljer att bortse från normaliseringsgraden (som är basen för alla databaser) för att öka prestandan i frågorna mot databasen. Det finns tillfällen när man dubbellagrar information för att öka prestandan i frågorn mot databasen, och det finns tillfällen då man väljer att skriva ut saker i klarttext istället för siffor i databasen av den enkla anledningen att man ofta läser datan från databasen. Ett typ exempel på det är en loggningsdatabas, här sparas alla loggningsinformation ner, och här skulle jag aldrig spara ner värden som integer om det komm från en enum i koden. Säg att du har en enum som heter Environment, denna kan innehålla typ: Development, Test, Production, eller 1,2,3 när man läser i databasen är det mycket trevligare att det står i klarttext vilken miljö man körde mot än en siffra. Men återigen det är om du har ett stor behov av att läsa tabellerna i databasen, har du inte det, så finns det ingen som helst anledning att spara ner det som text och ta extra uttrymme och prestanda i anspråk.

Du behöver inte sätta några siffor på din enumvärden, de börjar automatiskt räknas på 1 och sedan räknas upp för varje val, det är dock rätt bra att göra det, så kanske du tänker dig för innan du stoppar in ett nytt värde emellan de två du har, och värdet 2 i databasen får en helt ny innebörd.

- M

Gladh skrev:

Du behöver inte sätta några siffor på din enumvärden, de börjar automatiskt räknas på 1 och sedan räknas upp för varje val, det är dock rätt bra att göra det, så kanske du tänker dig för innan du stoppar in ett nytt värde emellan de två du har, och värdet 2 i databasen får en helt ny innebörd.

- M

Nja, de börjar på noll som default

spango skrev:

Smartare är väl att typomvandla en gång för alla, och då en int till enumtypen, istället för tvärtom:

Naturligtvis, smart! Tack! :bire