27. august 2007 - 18:42Der er
7 kommentarer og 1 løsning
Håndtering af data (arkitektur)
Hej,
Jeg er i øjeblikket i gang med en større applikation, og er i den forbindelse ved at blive en smule frustreret over planlægningen af min arkitektur. I den forbindelse har jeg nogle spørgsmål med hensyn til access af data.
Jeg har et objekt som blandt andet indeholder en property, med en liste af sig selv (hierarki). Dette objekt indeholder blandt andet data som skal benyttes til renderingen af hver enkelt webside, og vil dermed meget ofte blive tilgået.
Mit problem er nu hvorvidt jeg bør indlæse alt hierarkisk data i dette objekt når jeg forsøger at hente det gennem min ’DataProvider’, eller om denne egenskab burde kalde en anden funktion i dataprovideren, for at hente den nødvendige data ’on-demand’. Der vil komme scenarier hvor jeg har brug for disse data i objektet, ligeledes vil der også være scenarier hvor dette ikke vil være nødvendigt.
Næste ting er denne ’DataProvider’. (Vi snakker om en datamængde på mellem 20kb og måske optil 100kb) Bør denne læse på disken hver gang den bliver bedt om at hente noget data, eller vil det være forsvarligt, at cache alt dette data ved Application_Start og derefter hente data herfra?
Næst sidste spørgsmål går på designet af klasserne i min ’DataProvider’. Bør jeg lave klasser med en masse statiske funktioner (GetObject(), UpdateObject() etc.), eller vil det være smartere at have en instans af en DataProvider-klasse, og kalde funktionerne derfra?
Til sidst kommer endnu et klasse-design spørgsmål. Bør signaturen til fx en update eller insert-funktion være:
Jeg håber i kan hjælpe mig med mine problemer. Jeg bliver nødt til at have dette på plads før jeg går videre, og min hjerne bliver sur på min når jeg tænker mere over det :)
Du maa enten vurdere hvad der er hurtigst eller lave noget test.
Bemaerk at teknikken kaldet "lazy loading" er alment kendt. Og visse ORM software kan faktisk slaa det til og fra per klasse via en konfigurations fil.
Static metoder er OK, men du boer ikke have static fields. D.v.s. bruger de static metoder kun lokale variable, saa gaar det.
Men brug af instans og ikke-static metoder giver mulighed for at bruge interfaces og udskifte implementationen uden at paavirke de oevre lag, saa jeg vil anbefale den loesning alligevel.
Til #4, Hvis jeg giver et objekt til fuktionen, i stedet for en stribe parametre, hvordan bør jeg så håndtere ID’er?
I forbindelse med implementeringen af data-access-klasser har jeg et supplerende spørgsmål. Hvis jeg nu laver et interface til med Get, Inser etc. funktioner, vil det så være smart at implementere dette interface på alle lagene gennem arkitekturen (BLL, DAL, etc.), eller er der noget jeg har overset?
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.