Hejsan

I mina klasser så har jag gjort så att det finns en flagga som kontrollerar om mar har ändrat något i klassen sedan man läste in den i databasen. Anledningen till att jag har detta är att om man inte ändrar något så behöver man inte spara ner till databasen och således så sparar man lite trafik..

Undrar hur ni andra gör, tänker ni på detta eller struntar ni i det.. Anledningen till att jag funderar på det är för då man har en lite mer komplex struktur så blir det en hel del extra jobb som kanske i pricip är onödigt.. lr?

exempel
orders[2].orderrow[1].item.price

exemplevis om man plockar ut alla orders. och ändrar priset på en item.(Dåligt exempel kanske..) Orders objektet kommer då veta om att det finns en förändring i något objekt som finns i denna listan. Då man sedan kör orders.save(); så kommer den att leta upp de objekten som har förändringar och kalla på deras save metod. Man spara ju onekligen en hel del trafik på nätverket men frågan är om det är värt det.


/w

Jag tycker defintivt att det är värt det, och använder samma mönster själv.

Trafik till DBn är inget man skall ta lätt på, öppnar för en möjlig flaskhals och de skall vi av skalbarhetsskäl undvika in i det sista.

Dessutom ökar det chansen för konflikter mellan information. Det kan ju vara så att någon ändrat någon av de rader du har fått upp, om du då inte förösker uppdatera till ett gammalt värde, behöver du inte oroa dig för det, bara dem du själv ändrat som behöver tas om hand om.

Intressant..

Får man fråga hur du har löst det?

Jag har löst det som så att då något förändras skickar jag helt sonika ett event som tex parents kan lyssna på. I förra inläggets exempel så hade jag en orders collection som fångade händelsen och denna i sin tur poppar ytterligare en event som kan fångas av gränssnittet. Det blir mycket events, och hade en kille som tittade på det som tyckte detta var helt galet.. Dock sitter man på sin kammare å har ingen direkt att bolla idéer med så hade varit skoj med feedback..

Det finns väl egentligen två vettiga lösningar, det ena att publicera ett event och låta parent-objektet lyssna på det. Den andra metoden är att låta alla objekt ha en IsDirty-property och låta parent-objektet fråga objekten om det är "dirty".

Vill man göra saker då en förändring (som kräver en save) sker (t ex enabla en save-knapp) så är ju event-modellen att föredra.

Jag har svårt att se varför din modell skulle vara så fel.

Ja, jag ser inte heller något problem med det men motiveringen jag fick var att det blev alldeles för många händelser events och att dessa inte bör användas på det sättet (?)


/w

Utveckling idag handlar enligt min erfarenhet väldigt lite om minnesoptimering, prestandaoptimering och så vidare, i alla fall inte på den nivån som du beskriver. Om du inte (och dina kunder/användare inte) upplever ett prestandaproblem så har du heller inget prestandaproblem.

I ditt fall så handlar det ju om att antingen trigga ett event och meddela att en förändring har skett, eller så måste man kolla en property. I båda fallen blir det ett funktionsanrop. Om bara ett objekt prenumererar på eventet så kommer det ju bara att göras ett funktionsanrop så jag tvivlar på att det är så stor prestandaskillnad. Men det är bara en gissning, då jag inte är insatt i arkitekturen bakom events.

Visst "ska man" använda StringBuilder i stället för String-datatypen om man ska pussla ihop en massa delsträngar, men allvarligt talat, hur ofta märker man i slutprodukten om man gjort det eller inte? O s v...