GrynetMedlem sedan maj 2001329 inlägg Jag brukar alltid skapa en User klass som har Context.User som en property och some en konstruktor. Så i Global.asax när en ny session startas skapar jag en användare och kollar om denna är authentiserad och hämtar i så fall DB grejer annars tomt. Detta objekt stoppar jag sen i en sessions variabel.
Typ:
Session["User"] = new MyNamespace.User(Context.User);
Denna klass user innehåller all funktionalitet och properties som tillhör en inloggad person (inget annat).
Den innehåller då alltså även en properti som heter Person. Denna person innehåller all data som tillhör en användare av systemet. Tex adress namn etc.
Detta så att man med User klassen kan sköta allt som har att göra med rättigheter att komma åt sidor etc. Och för Person klassen allt som har med att visa användarna och allt gått och smått som tillhör dem. Detta eftersom man allt som oftast behöver skapa en lista av användare för att visa och vem vill då ha funktionalitet på dessa användare som login, rättigheter och change password etc??
Någon mera som gör så här eller har ni andra ideer?
Ursäkta utflummningen från huvudfrågan, men kände mig tvungen att spinna vidare på herr renholm.
Så tebax till den. Skulle jag ha gjort den så skulle jag alltså lagt en hashtabel eller nått annat med key-value pair som en property antingen på user eller person klassen beroende på vem den tillhör.
tex:
private attributes = new Hashtable();
public Hashtable Attributes{
get{
return attributes;
}
}
Jag väljer att ge åtkomst till hashtabelen direkt så att man kan styra attributen som en egen klass och inte styra attributen via usern. För varför ska en user ha metoden ClearAttributes på sig.
jaja..hoppas att det inte blev för flummigt igen.
Ha det gott :f
ptypeMedlem sedan juni 2002151 inlägg
Men vad är skillnaden mellan en länkad lista och den lista som du har för varje position i din hachtabell? Ursäkta om det blir OT, men det skulle vara kul att förstå det här lite bättre.
I en länkad lista har du länkar mellan objekten sinsemellan, och måste alltså traversera genom många (från början tills du hittat rätt) objekt för att nå ett visst objekt. I en hashtabell utgår du från objektet, räknar ut på vilken position den borde finnas i arrayen (hashvärdet) och dyker in direkt där (adresserar). Ganska stor skillnad alltså.
Det jag fått lära mig är att en vanlig array har en pekare, sedan ligger arrayen där med en bestämd längd. EN länkad lista har pekare från varje object och kan därför vara dynamiskt lång. Detta gäller väl även för varje given plats i en hachtabell, där du kan ha en dynamisk längd på listan?
En hashtabell har normalt inte dynamisk längd, men nuförtiden kan ju arrayer (och därmed hashtabeller) ha dynamisk längd. Vad man (läs frameworket) gör då är att man skapar en ny större array när den gamla börjar bli full.
GrynetMedlem sedan maj 2001329 inlägg
och dyker in direkt där (adresserar). Ganska stor skillnad alltså.
Oftast (alltid) dyker man alltså in i en länkad list då. DEt är det Network menar.
ZyaxMedlem sedan mars 200262 inlägg Japp för en dålig hashfunktion gör att alla objekt "hashas" till samma plats i arrayen och läggs i samma länkade lista.
Alltså är en hashtabell en array av länkade listor...
ptypeMedlem sedan juni 2002151 inlägg
Oftast (alltid) dyker man alltså in i en länkad list då. DEt är det Network menar.
Förstår inte hur han menar??? Det finns ingen länkad lista där.
ZyaxMedlem sedan mars 200262 inlägg Hur tror du två objekt sparas på samma plats i arrayen som är Hashtabellens bas. Jo en länkad lista...
ZyaxMedlem sedan mars 200262 inlägg Men det är ointressant för vi struntar i när .NET sköter det åt oss!
NETworkMedlem sedan juni 20011 732 inlägg
Zyax skrev:
Japp för en dålig hashfunktion gör att alla objekt "hashas" till samma plats i arrayen och läggs i samma länkade lista.
Alltså är en hashtabell en array av länkade listor...
Ja, det var så jag menade. En hashtabell har väl en pekare för varje objekt som är lagrad för varje position i hashtabellen, du kan ju inte exakt veta var objektet finns lagrat utan bara på vilken plats i en given längd som ju sedan kan innehålla noll eller flera objekt. Så här tänker jag:
1234
aaaa
bbb
cc
d
Om jag ska komma åt 1d så vet hastabellen att den ska söka under 1 men sedan måste den gå genom a till b och slutligen c för att hitta d. Alltså är a-b-c-d en länkad lista som är på position 1 i hashtabellen. ELler tänker jag fel?
ptypeMedlem sedan juni 2002151 inlägg
Hur tror du två objekt sparas på samma plats i arrayen som är Hashtabellens bas. Jo en länkad lista...
En hashtabell har väl en pekare för varje objekt som är lagrad för varje position i hashtabellen, du kan ju inte exakt veta var objektet finns lagrat utan bara på vilken plats i en given längd som ju sedan kan innehålla noll eller flera objekt.
Nej, två objekt sparas inte på "samma plats". Är platsen upptagen använder man en annan plats. I de enklaste implementationerna nästa plats i arrayen, i de mer avancerade hoppar man ett visst antal steg framåt enligt en algoritm (där stegen blir större varje gång). Ingen länkad lista alltså.
ELler tänker jag fel?
Ja ;) Men det var en bra gissning.
renholmMedlem sedan apr. 20012 266 inlägg Tycker tråden börjar sväva ut i en diskution om hashtables. Den ursprungliga frågan var hur man på bästa sätt sparar ner användar specifika inställningar från en databas, var av Hashtable är ett alternativ.
ZyaxMedlem sedan mars 200262 inlägg Innan renholm stänger denna diskussionen måste jag påpeka att ptype har fel.
En plats i arrayen håller flera objekt (i en länkad lista), det är liksom det som hashing betyder. För att hashtabellen skall utnyttjas rätt skall det vara lagom lång array och lagom långa länkade listor i arrayen.
ptypeMedlem sedan juni 2002151 inlägg 1. Det var ju en av moderatorerna som initierade OT:n.
2. Nej Zyax. Du har fel. Jag har rätt. Jag har undervisat om detta på universitetet, så jag vet nog vad jag talar om.
ZyaxMedlem sedan mars 200262 inlägg Separate Chaining - Separate chaining is a method for dealing with collisions. The hash table is an array of linked lists. Data elements that hash to the same value are stored in a linked list originating from the index equivalent of their hash value.
ZyaxMedlem sedan mars 200262 inlägg http://www.it-c.dk/research/algorithms/Kurser/Intro/WWWkursus/notes/HASHING.html
Läs och begrunda!
ptype: Du får gärna beskriva vad som händer om kollisioner händer i din hashtabell!
ptypeMedlem sedan juni 2002151 inlägg Då är det en speciell form av hashtabell (Separate Chaining) Det är klart man kan välja att implementera en hashtabell på det sättet, men så är inte fallet i en enkel ursprunglig hashtabell.
Jag har redan beskrivit hur kollisioner fungerar. Jag skrev: Är platsen upptagen använder man en annan plats. I de enklaste implementationerna nästa plats i arrayen, i de mer avancerade hoppar man ett visst antal steg framåt enligt en algoritm (där stegen blir större varje gång).
ZyaxMedlem sedan mars 200262 inlägg Jag ger mig :)
Jag har nu läst .NET-referensen och upptäckt att .NET använder sig av en typ av hashtabell som ptype beskriver. Vid kollision så hashas alltså objektet om och hamnar på ett annat index.
Dock bör ju ptype känna till den typ av hashtabell som inte är kollisionsfri, alltså den som jag skrivit om!
ptypeMedlem sedan juni 2002151 inlägg
En plats i arrayen håller flera objekt (i en länkad lista), det är liksom det som hashing betyder.
Nej, hashing är att utifrån ett objekt räkna ut en position.
The function that maps a key value to the array index in which that key (and its associated data) will be stored is called the hash function.
ZyaxMedlem sedan mars 200262 inlägg Ordo är lägre vid insert i en hashtabell som grundar sig på chaining, det är skillnaden. Behöver ej någon vidare uppfattning om hur många element jag skall hantera!
PMedlem sedan jan. 20012 204 inlägg gahh! vilken jäkla diskussion.... fattar inte ett smack och hash-tabeller verkar ju vara rena snårskogen!
