Hej!

Har läst DDD av Evans och Applying DDD av Jimmy Nilsson och nu ska det baske mig bli slut på Recordset-tänkandet!

Det jag inte riktigt blir klok på är hur man använder sina entities och repositories på bästa sätt i ASP.NET-miljö. Har Googlat runt en hel del för att hitta exempel, men jag hittade inget. De flesta exempel utgår från WinForms-miljö där objekten finns tillgängliga under hela dialogens livslängd och så är ju inte fallet här.

Efter lite experimenterande har jag kommit fram till följande:

Jag har ett repository för att hantera Orders och OrderRows som kallas OrderRepository. Eftersom jag antar att det är bäst att implementera OrderRepository som ett Singleton har jag satt alla metoder, properties och attribut till shared (VB.NET). Objekt som har hämtats från DB eller skapats lagras i en IList (Dictionary) för att sen sparas i DB vid PersistAll eller liknande.

Processen för att ändra ett Order-objekt kan då bli:
-Hämta ordern från repositoryt. Finns den inte i Dictionaryt hämtas den från DB.
-Spara orderns nuvarande state genom att spara objektet i Session
-När användaren har gjort sina ändringar hämtas ordern på nytt från repositoryt och efter en jämförelse med det sparade objektet kan man antingen spara eller varna användaren om det har skett förändringar sen objektet hämtades.

Jag vet att det är ett stort no-no att spara objekt i Session, men det kommer bara att vara ett fåtal användare som gör detta. Kanske ett tiotal simultant. Viewstate känns inte som ett alternativ eftersom det kan bli så mycket data att ladda ner till klienten.

Vad tror ni? Det känns iaf som ett steg framåt jämfört med använda DataRows för läsning och dynamisk SQL vid sparande... :-)

/Fredrik

du kan ju använd cachen

Jo det kan man ju göra, men då blir det ju en massa typecasting. Dessutom verkar prestanda bli bättre om man använder static istället för Application/Cache:

http://www.google.se/search?source=ig&hl=sv&q=Using+static+variables+instead+of+the+Application+object&meta=

jag menade inte application object jag menar System.Web.Caching.Cache
men visst statics funkar ju det med men om du kollar i den femte träffen på din sökning så står det lite om multitrådade miljön som är på webservern då du kan få problem med att skriva oh läsa i globala objekt. http://www.thescripts.com/forum/thread318506.html

kolla in artikeln http://msdn2.microsoft.com/en-us/library/aa478965.aspx
där står rätt mycket matnyttigt om cachen.

>Det jag inte riktigt blir klok på är hur man använder sina entities och repositories på bästa sätt i ASP.NET-miljö.

Som du antyder lite så finns det massor med sätt att hantera dem på. Somliga bra somliga dåliga.
Allt handlar i grund och botten om de krav man har.

En typisk lagerarkitektur för DDD är ex:
UI
Application/Service Layer
DDD

Där ett Infrastruktur lager drar sig över alla 3. Dvs där du har stöd klasser så som
DataAccess klasser, UI-relatterade klasser m.m.

Notmalt sätt så använder jag oftast ObjectDatasource på UI nivå där jag pratar med ett objekt
som ligger i Application/service layer som i sin tur pratar mot Repositories och mina Entiteter m.m.
Det är i Application layer jag sen ev kör cache för UI objekt. Kan kolla lite concurrency.
Antingen Pessimistic eller Optimistik. Det låter som det är det du vill göra när du lägger dem i session.

jag använder Aldrig cache eller liknande innan jag vet att jag behöver det. Prestandan är så snabb i dagens datorer så oftast har vi inga problem att tillfredställa kundens krav på antal användare.
När jag är klar och allt fungerar då väl kan jag kasta in cachehantering om jag märker att jag inte kan
uppfylla kraven. Då har jag två val jag brukar nyttja.

Cache för UI saker lägger jag i UI delen. Cache med data lägger jag ev i mina Reposritories (ID Entity map pattern.)

Mina respositories är aldrig rena singletons.

Mvh johan
www.johannormen.com/blog