11. april 2007 - 20:14Der er
16 kommentarer og 1 løsning
static member vs. Application objektet
Hej eksperter,
Jeg er forholdsvis ny i .net verdenen, har dog kodet en del old school ASP. Jeg er ved at lave et større website, og har i den forbindelse lavet en dll, hvor jeg ikke umiddelbart har adgang til Application objektet. Jeg vil da høre, om man bare kan lave et static member på en klasse i stedet for. Jeg har afprøvet det, og det ser ud til at virke, men er det sikkert?
Teknologi, AI og forretning er i centrum på Computerworlds Cloud og AI Festival i København d. 18. og 19. september. Se hele programmet for den store konference om strategisk brug af Cloud og AI på: www.cloud-festival.dk
arne_v>> Jeg har lavet en singleton, men jeg er ikke bekendt med, at dette kan gøres uden brug af et static members???
Spørsmålet var nu heller ikke om hvad der er god skik eller ej, men om der er nogle der har erfaring med at bruge static members frem for Application objektet.
Fint nok. Jeg har lavet et "naming" interface, som dll'en kan bruge til at få fat i eksterne resourcer, så i princippet vil jeg gennem dette interface kunne tilgå variable gemt i Application objektet. Spørgsmålet er fortsat, om hvad jeg får ud af at bruge Application objektet frem for static fields?. Eller formuleret på en anden måde: er Application objektet kun med for bagudkompatibilitet?
spoergsmaalet om hvorfor Application er bedre end static fields kan ikke besvares uden at komme ind paa god skik og brug - sig til hvis du skifter mening med hensyn til det
Application er der ikke p.g.a. bagud-komapbiltet men fordi det er en nyttig feature
Jeg synes du er en anelse belærende lige nu. Jeg er uddannet datalog og har mange års erfaring som systemudvikler. Jeg har en rimelig føling med hvad der er god skik og brug, men som sagt er det ikke det som spørgsmålet handler om. Jeg søger en teknisk forklaring på forskellen!
Og Application objektet giver saa en mulighed for at have information med application scope uden brug af public static fields og uden at man selv skal lave singleton klasser.
Hvis du taenker paa thread safety i en public static fields versus ikke static methods/properties i et objekt der gemmes i Application, saa er der iukke nogen principiel forskel udover at der skal findes et passende synch objekt for foerstnaevnte.
Ikke i forhold til dit eksempel. Vi skal begge initialisere variablen et sted, f.eks. i Application.Start eventet. Her skal jeg sætte min property med et instans af en konkret implentation af INoget, men det skal du jo også.
sorry - jeg troede at det var det objekt du returnerede at du ville bruge static property i
det er helt fint - om du bruger den måde eller om du har en static property i en egen singleton class eller om du bruger Application property af din page class som altid peger på samme objekt må være hip som hap
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.