Avatar billede nico26 Nybegynder
11. april 2007 - 20:14 Der 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?

På forhånd tak
Avatar billede arne_v Ekspert
11. april 2007 - 20:19 #1
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)
Avatar billede nico26 Nybegynder
11. april 2007 - 22:09 #2
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.
Avatar billede nico26 Nybegynder
11. april 2007 - 22:11 #3
Forøvrigt kan jeg ikke umiddelbart bruge HttpContext.Current.Application, da jeg også bruger dll'en i ikke webbaserede applikationer.
Avatar billede arne_v Ekspert
11. april 2007 - 22:21 #4
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
Avatar billede arne_v Ekspert
11. april 2007 - 22:26 #5
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
Avatar billede nico26 Nybegynder
11. april 2007 - 22:27 #6
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?
Avatar billede nico26 Nybegynder
11. april 2007 - 22:29 #7
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.
Avatar billede arne_v Ekspert
11. april 2007 - 22:44 #8
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
Avatar billede nico26 Nybegynder
11. april 2007 - 22:50 #9
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!
Avatar billede arne_v Ekspert
11. april 2007 - 22:57 #10
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.
Avatar billede arne_v Ekspert
11. april 2007 - 23:04 #11
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.
Avatar billede nico26 Nybegynder
11. april 2007 - 23:05 #12
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...
Avatar billede arne_v Ekspert
11. april 2007 - 23:07 #13
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.
Avatar billede arne_v Ekspert
11. april 2007 - 23:13 #14
kun delvist

static properties & methods kan ikke laves virtual, hvilket du har brug for
Avatar billede nico26 Nybegynder
11. april 2007 - 23:22 #15
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å.
Avatar billede arne_v Ekspert
12. april 2007 - 01:16 #16
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
Avatar billede nico26 Nybegynder
20. maj 2007 - 19:02 #17
lukker
Avatar billede Ny bruger Nybegynder

Din løsning...

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.

Loading billede Opret Preview
Kategori
IT-kurser om Microsoft 365, sikkerhed, personlig vækst, udvikling, digital markedsføring, grafisk design, SAP og forretningsanalyse.

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester