Jag har en klient applikation skriven i WPF som jag försöker implementera med hjälp av M-V-VM pattern. Mitt problem är att min klient skall fungera i en offline situation också, så jag måste ha en cache på klientsidan som håller all aktuell data, dessutom så förbättrar det ju prestandan en del.

Vilket fall som helst så kommer mina collections mot WPF att vara ObservableCollection eftersom den kan användas till databindingen på ett smidigt sätt. Så säg att jag har en lista med Customer som jag hämtar från mitt WCFRepository och sedan visar på klient sidan. Jag vill nu placera en cache här så jag slipper hämta alla customer igen och igen vid varje förfrågan (jag har löst uppdateringen av customerlistan, så om en annan klient ändrar i någon customer så får jag reda på det). Mitt självklara val, var att skapa en domainservices som man måste gå igenom för att hämta CustomerListan, och där kontrollera om det finns något i cachen, och finns det inget så hämta via WCFRepositoryn.

Problemet blir då att om jag lägger till en Customer från min klient, så kan jag ju lägga till den till min cache, men inte på något smidigt sätt notificera min ViewModel att cachen är ändrad, så jag funderade på att ha cachen som en observablecollection också, och binda denna direkt till View via ViewModel, men dels så känns det som en riktigt hårdbinding, och dels så måste jag lägga till windowsBase.Dll till min Domainmodell, och det känns riktigt illa.

Jag funderade på att ha cachen i min ViewModel, men insåg att det blir inte speciellt bra med tanke på eventuell Add-logik kommer ligga i domainmodellen, och den har inte tillgång till ViewModellen.

Ett annant alternativ var att ha cachen som en vanlig Lista och lägga till en del event som ViewModellen skulle lyssna på och beroende på eventen så skulle viewmodellen utföra samma sak på sin observablecollection som den har i sitt minne, helt klart snyggast, men fy så mycket extra kod som måste implementeras...

Just nu känns det som det blir det första alternativet men jag gillar det inte riktigt, det är smidigast, men inte alls så snyggt som alternativ 3.

Någon som har gjort något liknande tidigare.

- M

Brottas med liknande spörsmål, men är ganska inne på att lägga själva cachningen i mitt repository, och underhålla listor därifrån (ev. via BindableLinq). Sen är det väl en smaksak om man vill binda direkt till BindingList/ObservableCollection, eller lägga ViewModel "ovanpå", och lyssna på events för att synka. Har gjort den lösningen tidigare, och det funkar, men är en del pyssel. Beror ju lite på hur man tänkt sej dom fysiska lagren också...

Jag har också kommit så långt att jag nog lägger cachingen i Repositoryt, det är ju dens uppgift att hämta data till mig, varifrån den kommer borde jag ju inte bry mig om...

Angående själva hanteringen av eventen så är jag fortfarande kluven, en observabelCollection bör det ju knappast var så långt nere som i repositoryn, kanske skall fixa 2 egna collection, en för att ha i cachen där jag lägger på lite event, och en som skall vara i presentationslagret som kan instanseras med en collection från cachen (och i princip wrappa den), där presentationcollection lyssnar på eventen från cachcollection och kastar de vidare...

Får se hoppas på lite mer input...

- M

Jag flyttade ner min cache i mitt repository och la min collection där som en observablecollection och det fungerarde hur bra som helst, så fort något lades till eller togs bort från min cache så slog det igenom direkt i GUI:et.

Men om jag ändrade värden i mina objekt (domänobjekt) så hände inget och givetviss de implementade ju inte INotifyPropertyChanged, så du fick de göra det och vips så fungeraded det med, men nu är mina domänentitets "märkta" av vilket GUI jag använder. Inte speciellt snyggt...

Det här suger fet, just nu, får försöka hitta något smidigt sätt att lösa detta på, det räcker inte med att mina presentationscollections skall wrappa cachadecollections, presentationscollections måste även innehålla presentationsentity som skall wrappa mina domänentity, och på något magiskt sätt skall det fungera och samtidigt vara enkelt att arbeta med...

Tips någon!?!?!?!?

Det här med cachning och vart man ska cacha kan ibland vara lite svårt att bestämma. Tex om vi har affärslogik som påverkar vår "data", ska inte datan efter logiken cachas? eller vill vi cacha den data vår affärslogik får, men då kommer vi ändå få samma data från vår logik, men logiken måste alltid köras och då kanske helt i onödan. Jag brukar ofta cacha på presentationlager nivå.. delvis för att undvika köra logik och det är ofta så att jag vill cacha den data som ska visas.. men det beror på applikationen och vad den gör.. så jag kan aldrig säga att jag ALLTID cachar på presentationslager nivå..

Det löser ju mitt problem med att jag slipper ha observableCollection i min domän, eller i mitt repository. Och det borde vara relativt enkelt att hantera PresenationsEntity jmf domänentity.

Men hur löser du problemet om du lägger till en nytt objekt, då skall du ju både uppdatera din cache, och skicka informationen till ditt repository. Den logiken borde ju knappast presentationslagret behöva bry sig om, det låter mer som det är något för ditt domänlager att fixa i en domänservices eller applikationservices. Man skulle ju kunna lösa det med event från domänlagret som cachen lyssnar på, men det tycker jag blir onödigt komplext, speciellt om det är många collections som skall hållas i cachen.

- M

Jag är ingen expert på det där mönstret men vad jag har fattat det som så är VM (ViewModel) det man kopplar mot UI:t dvs man kapslar in sina Entiteter så som du beskriver i en av lösningarna, samt kapslar in listorna i ObservableCollection och sedan mappar förändringarna med varandra ner till repository eller dylikt, där du egentligen kan ha din cache ändå. Sedan om din cache uppdateras så skulle du kunna ha någon typ av egen Observable implemmentation på repositoryn som skickar event när något uppdateras.