14. august 2003 - 13:24Der er
12 kommentarer og 1 løsning
"Overfør objekt" fra aspx til ascx
Okay det er sikkert simpelt det her, men jeg kan ikke finde et svar nogen steder...
Jeg har en side som bruger nogle kontroller lavet som ascx-filer til at vise nogle menu-elementer.
Til det formål har jeg oprettet nogle menuklasser, som lige nu ligger i en include fil, jeg inkluderer i hver ascx fil der skal bruge menuen. Hver ascx-fil opretter altså sit eget menuobjekt vha. klasserne, som den så bruger til at skrive bestemte dele af menuen ud.
Men det er jo ikke smart - det ville være smartere hvis ascx-filerne kunne deles om menuobjektet, så skulle det kun oprettes en gang, og jeg sparer på den måde noget hukommelse og nogle kald til databasen.
Tanken var så at oprette menuobjektet 1 gang på den aspx side der kalder ascx-filerne, og så overføre menuobjektet til ascx-filerne herfra.
Men hvordan gør man det? Jeg har prøvet at oprette en "Public" variabel i ascx filen som jeg så binder til menuobjektet fra aspx filen, men kan ikke få det til at virke.
Efter mit hoved bør du lagde ascx styre det den har brug for. Meningen er jo at den står for en del af siden. Derfor bør den ikke være afhængig af hvad der sker i aspx delen af siden.
Vil forslå at du bruger et singleton pattern, derved vil du kun få oprettet objectet en gang. Det er også mulig at gemme objectet i cachen. Det vil også mindske kaldene til databasen.
Jeg kan godt se dine pointer, cachen er dog er problem idet menuen bliver opdateret fra et CMS der endnu ikke er porteret til ASP.NET, og jeg kan derfor ikke styre hvornår objektet skal slettes fra cachen på en fornuftig måde.
Hvordan implmenterer jeg et singleton pattern på klassen? I .NET dokumentationen er alle Singleton eksempler jeg kan finde forbundet med remoting, og jeg kan ikke rigtig finde ud af hvordan jeg skal bruge det på en klasse der oprettes fra aspx side.
Well, ved brug af singleton får du jo et object, som lever videre mellem request. Og den vil derfor heller ikke være så god.
Kan du ikke bare benytte cache og så sige at den kun må overleve 1-2 min ad gangen. Menuen bliver vel ikke opdateret så tit, og bare administratorne er klar over det. Hvis der er mange besøgende på siden er 1-2 min. cache faktisk en god performance boost.
-> Singleton Ja - måske kan man bruge det dokumentationen omtaler som "SingleCall", så vidt jeg forstår virker som Singleton, men kun for hvert request, jeg mangler dog stadig nogle eksempler jeg kan forstå. :(
-> Cache Jo det kan jeg selvfølgelig, men det vil forringe usability på mit CMS, så det tror jeg jeg venter med, alternativet kunne vel være at lave en funktion på klassen, som på en eller anden måde checker om objektet i cachen skal opdateres og kalde den en gang for hvert request - det vil jeg lige tænke over.
Jeg tænker over det og lader spørgsmålet stå åbent lidt endnu, måske er der nogle andre der har nogle bud :O
Synes personlig at cachen er god. Det med at tjekke om den skal opdateres for hvert request, giver desværre lidt det samme, at du skal have lavet et kald.
Alternativt kan du gemme oplysningerne i din HttpContext. HttpContext.Current.Items tror jeg at den hedder. Så laver du bare en statisk metode som du kan kalde fra dine usercontrols. De tjekker så om objectet er lagt i din "HttpContext", hvis den ikke er, skal objectet lave en lås og instancere objectet og derefter gemme den i contexten og lås op igen. På den måde vil du kun få lavet objectet en gang per request.
Alternativt igen kan du lave en httphandler som laver dit object for hvert request. Men der må du selv lige lave noget resource om det nu også er en smart ide.
quaser>> du siger at et singleton-object lever mellem request's ?! hvad har du at underbygge den påstand ? Jeg kan ikke umiddelbart se det logiske i det, da et object der følger singleton-pattern jo bare er et helt normalt object:
public class SingletonObject { //Field til at holde instansen af objectet private singletonObject SingletonObject = null;
// Gør at man ikke kan kalde constructoren udefra private SingletonObject() {
}
public SingletonObject Instance { get { // Gør brug af lazy initialisering if (singletonObject == null){ singletonObject = new SingletonObject(); }
dow... ja... det har du ret i... jeg hader at skrive kode i et textarea :P
du har ret i, at singleton bliver brugt til at sørge for at der kun bliver lavet et object af en klasse. hvordan det helt præcis fungerer i forbindelse med asp.net skal jeg ikke gøre mig klog på, men jeg har dog altid forestillet mig, at den tid et object lever i, går fra at der kommer et request ind, og indtil at response er blevet skrevet ud igen.
dog burde man vel kunne oprette et singleton-object og gemme referencen i en Application-variabel. På den måde burde man kunne opretholde f.eks. en collection mellem request's ?!
Mht. singleton objekters levetid passer det fint med mit behov hvis det kun lever i request'et, mit oprindelige problem gik på at jeg havde et forholdsvis omfanttende objekt, som jeg oprettede 3-4 instances af for hvert request, fordi hver ascx fil der benyttede menuobjektet oprettede sit eget menuobjekt.
Hvorvidt det samme objekt lever over hele requestet har jeg ikke haft tid til at checke, men jeg lover at vende tilbage når/hvis det lykkes at får det på plads.
cyberfessor >> Jeg har benyttet metoden i et jsp/servlet program engang tilbage i min skoletid hvor der skulle oprettes et object som sørgede for at kommunikere med en corba service. Fungerede fint. Eller også var det den gruppe vi samarbejdede med der gjorde det sådan og vi så brugte en anden. Kan jeg ikke lige huske, men det kunne da lade sig gøre.
jhauge>> netop til det vil jeg mene, at et singleton-object kan bruges i forbindelse med asp.net. Som jeg selv siger, så ved jeg det ikke 100 %, men jeg tvivler på at et object får lov at leve over flere request's. Jeg mener... med mindre man har gemt referencen et mere "holdbart" sted, så vil der jo blive oprettet nye objecter med nye referencer når siden loades anden gang.
Synes godt om
Ny brugerNybegynder
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.
