static member vs. Application objektet

public static fields er et no no i OOP

du kan bruge et sing;eton objekt

eller fiske en referance til Application (HttpContext.Current.Application mener jeg)

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.

Forøvrigt kan jeg ikke umiddelbart bruge HttpContext.Current.Application, da jeg også bruger dll'en i ikke webbaserede applikationer.

du skal bruge static members, men bemaerk at jeg sagde "public static fields"

et private static field og en static metode er naturligvis noedvendige

----

hvis programmet skal bruges i anden kontekst end web skal du naturligvis
bruge singleton

og jeg ved ikke rigtigt hvad du vil bruge det til, hvis du kan faa en eller anden
til at tilstaa at han har brugt public static fields

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?

arne_v>>Det er dig der har bragt "public static fields" på bane. Spørgsmålet går ikke på hvad der er god skik.

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!

Forskellen er at du med brug af en klasse med public static fields binder al
kode der bruger den til implementationen.

Hvis du bruger Application kan du definere et interface eller en abstract class
med nogle abstrakte properties og lade al den brugende kode bruge:

INoget o = (INoget)Application["Noget"];

Og have friheden til at skifte intern implementations logik ud og friheden til
f.eks. at skifte implementation by configuration.

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.

arne_v>>den egenskab opnår du i kraft af din brug af interfaces - ikke Application objektet. Jeg kan opnå de samme egenskaber med en statisk property.

class
{
  ...
  public static INoget Noget { get; set; }
}

Anyway, det er stadig ikke helt det som jeg søger...

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.

kun delvist

static properties & methods kan ikke laves virtual, hvilket du har brug for

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

lukker