15. august 2010 - 13:35Der er
19 kommentarer og 2 løsninger
Sætte en værdi i en anden projekt
Hejsa,
Jeg har følgende projekter i en solution:
Portal Denne indeholder min DBUtility - altså her jeg sætter min datasets/datatables osv. op i forskellige metoder.
Portal.Library Denne indeholder min DAL - altså metoder til at hente/indsætte/opdatere/slette i databasen. Jeg laver her en reference til Portal projektet og bruger metoderne fra Portal her.
Portal.Web Det er så selve hjemmesiden/grafiske layout, hvor jeg bruger metoder fra Portal.Library. Jeg laver her en reference til Portal.Library.
Nu er det så, jeg frygtelig gerne vil sætte en værdi i Portal.Web, som skal bruges i Portal (til at bestemme om, den skal cache de tabeller, der hentes fra databasen eller ej. I Portal vil jeg så spørge på den værdi for at bestemme dette....
Men jeg tør ikke bare tilføje en reference i Portal til Portal.Web - for aner jo ikke hvad der sker....Vil programmet køre i loop eller hvad...
Eller hvordan gør jeg det Portal | Portal.Library | Portal.Web
og så
Portal.Web | Portal
En af metoderne i Portal der skal have en værdi fra Portal.Web ser ud som følgende:
Du kan refere til et projekt der allerede har en reference til projektet.
Dvs:
main (referere til sub) -> sub := main kan tilgå sub
sub (refere main) -> main (refere sub) := vil give en løkke som ikke er muligt. Det giver en compile error.
Af mulige løsninger:
- Et helt andet projekt der kan indeholde data, som både sub og main har tilføjet referencer til - Tilføj værdien i sub, så skal du bare have main til at sætte værdien i sub
Den sidste er nok den mest anvendelige, hvis det kun lige er den ene variabel du er ude efter
Mit problem er ja ja biiiig surprise.......min caching....
Den har jeg jo sat i mit portal lag.
Nu ville jeg så frygtelig gerne, at hvis UnoEuro skrev til mig (når sitet er i produktion), at det var et problem...det bruger for meget ram, at jeg så kunne via codebehind kunne sætte en værdi, der ændrede det til ikke at cache.... Så jeg ville blive fri for at skulle builde og publish'e én gang til.....
Så ja det er ren og skær magelighed fra min side, at jeg gerne vil kunne sætte en værdi i web delen som så slog igennem opad :-)
Det må være stadig være fordi din type er i dit web lag i stedet for dit portal lag. Hvorfor skulle dit portal lag eller skulle kende til dit web lag? Hvis det ikke var for at vide hvad for typer der var i det lag.
Aner ikke om det er hvad I har prøvet at fortælle mig - men har valgt at smide en ny parameter med en i de 2 metoder i Portal laget og så tilføje den parameter heeeeeele vejen ned, hvor jeg så i mit web lag definerer om den skal være true/false.... *suk* Mega meget arbejde....
Hvis én af jer, har forsøgt det - så smid et svar og I får jeres points :-)
Problemet som jeg ser det, er at du prøver at afkoble din solution ved at lave flere projekter, på den måde kan du også nemmere bruge dit Protal lag i andre projekter, men hvis du i dit Portal lag, kræver at den skal kunne se dit Web lag, så kan det jo ikke genbruges, hvis du ville lave en Windows Client.
Håber du kan følge ideen, og hvorfor du ikke skal gøre som du prøvede på :-)
Jeg har nu ændret min metode, som jeg viste i start indlægget og brugt de sidste par timer til at rette min kode nedad i systemet, så den tager en parameter(værdi) mere med ind i metoden, som så afgør om den skal cache eller ej.
SqlDataAdapter adpt = new SqlDataAdapter(_command);
DataSet dsCached = null; DataSet ds = new DataSet();
if (IsPortalCached) { OnCachedItemRemoved = new CacheItemRemovedCallback(this.CachedRemovedCallback); dsCached = System.Web.HttpContext.Current.Cache.Get(cacheName) as DataSet; }
if (dsCached == null) { try { if (_connection.State == System.Data.ConnectionState.Closed) { _connection.Open(); }
Det eneste jeg ville, var at jeg frygtelig gerne ville have haft sat værdien udenfor metoden (så jeg var fri for at ændre samtlige metoder, der bruger ovennævnte metode - ja ja jeg ER doven *griner*)
Vi må da ikke håbe det skal bruges til andet end inhouse.
simsen-> en god idé er altså at bruge noget tid på at forstå lag-principperne og nogenlunde følge design patterns. Det vil gøre koden nemmere at forstå og vedligeholde.
Portal.Web sender parameter til Portal.Library -> sender paramter til Portal der udfører koden.
Som Buzzz også siger, sørg for at når du deler dine projekter på i de dele, så skal du også sørge for at din Portal ikke er afhængig af Web -delen, så du får noget der kan bruges på andre måder.
Sørg for at dit under bibliotek indeholder de metoder der skal bruges, og de bliver sat ved et metode kald.
Så du får f.eks.:
Portal.Web { Portal.Library.update(bool cache) }
Portal.Library { Portal.update(bool cache) } Portal { update(bool cache) { kør din kode }
hej simsen... synes da ikke jeg har nedgjort dig, men ellers så tag imod min undskyldning.
Jeg synes ikke løsningerne er elegante og nu skriver du at du gerne vil lære :)
Du har stadigvæk en binding til web igennem System.Web.HttpContext.Current.Cache.Insert(cacheName, ds, null, cacheTime, TimeSpan.Zero, CacheItemPriority.Default, OnCachedItemRemoved);
Så... om du sætter en variabel igennem Library eller ej er et fedt. Og udover det er det altså fuldt tilladt at skrive sådan her: public bool IsPortalCached { get; set; }
...og så sætte den variabel fra web-lib-db, men det er httpcontexten i dit dal der ikke er ok!
Det som du måske skulle overveje var at lave en Cache-lag og så sætte det imellem dal og web, på den måde vil det også være nemmere at lave specielle regler for cachen + at du har et bedre overblik :) Sådan at cachelag må naturligvis gerne have kendskab til web og dal :)
Jeg har rent faktisk ikke tænkt over, at jeg binder web indhold i den der System.Web.HttpContext.Current.Cache.Insert i min Portal, før dit sidste indlæg. Jeg er fuldstændig grøn mht. caching og har så "bare" slavisk fuldt de tutorials jeg har googlet mig frem til.
Nu gør det ikke så meget i det her tilfælde, da det jeg er igang med altid kun vil være web baseret...
Mht. at sætte bool - så forsøgte jeg det faktisk først - men den slog ikke igennem. Altså jeg satte bool IsPortalCached {get, set} i Portal i DBUtility class og kunne så også lave en isPortalCached = true i Portal.Web - men når jeg så forsøgte at køre en af metoderne i DBUtility class, var IsPortalCached altid false....
Mht. Cache-lag (og fremtidig brug af min Portal projekt) - forstår jeg dig ret: At jeg skal lave et nyt projekt. I det nye projekt lave først metoder, der indsætter/henter i cachen - og så ellers lave metoder for hver metode i DAL, der binder metoden insert cache og hentning fra DAL eller hentning fra Cache ind i web delen?
At sætte isPortalCached skal kunne lade sig gøre, du skal sikre dig at du gør det på samme instans af Portal, ellers skal du lave den static!
altså. public static bool isPortalCached{get; set;} , så kan du sætte den hvorfra og hvornår du har lyst.
Ja du har forstået det korrekt, et nyt projekt. Nu er du ny og sådan... og det kan måske være en for stor mundfuld, men prøv at kigge lidt på generics, de vil være en stor hjælp i sådan et cachelag. Hvis du bruger det generiske kan du snildt anvende dit projekt/ assembly i andre løsninger. Langsomt vil du få opbygget en codebase som gør det nemmere for dig at udvikle.
lav et ICache interface som har de metoder du vil bruge.
Nu kan du lave en implementering af ICache og sende den med som parameter til dit Portal/DB lag ... måske også noget logik som afgør hvad der skal caches, som automatisk bliver kørt i din Add Method, der er mange muligheder.
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.
