Loggkonsekvensproviders

Paketet Microsoft.Orleans.EventSourcing innehåller flera log-konsekvensproviders som täcker grundläggande scenarier som är lämpliga för att komma igång och tillåter viss utökningsbarhet.

Tillståndslagring

Lagrar Orleans.EventSourcing.StateStorage.LogConsistencyProvider ögonblicksbilder av korntillstånd med hjälp av en standardlagringsprovider som kan konfigureras oberoende av varandra.

De data som lagras i lagringen är ett objekt som innehåller både korntillståndet (som anges av den första typparametern till JournaledGrain) och vissa metadata (versionsnumret och en särskild tagg som används för att undvika duplicering av händelser när lagringsåtkomsten misslyckas).

Eftersom hela korntillståndet läs-/skrivs varje gång vi kommer åt lagringen är den här providern inte lämplig för objekt vars korntillstånd är mycket stort.

Den här providern stöder RetrieveConfirmedEventsinte , den kan inte hämta händelserna från lagringen eftersom händelserna inte sparas.

Logglagring

Lagrar Orleans.EventSourcing.LogStorage.LogConsistencyProvider den fullständiga händelsesekvensen som ett enda objekt med hjälp av en standardlagringsprovider som kan konfigureras oberoende av varandra.

De data som lagras i lagringen är ett objekt som innehåller en List<EventType> object, och vissa metadata (en särskild tagg som används för att undvika duplicering av händelser när lagringsåtkomster misslyckas).

Den här providern stöder RetrieveConfirmedEvents. Alla händelser är alltid tillgängliga och bevaras i minnet.

Eftersom hela händelsesekvensen läs-/skrivs varje gång vi kommer åt lagringen är den här providern inte lämplig för användning i produktion, såvida inte händelsesekvenserna garanteras förbli ganska korta. Huvudsyftet med den här providern är att illustrera semantiken för händelsekällorna och för exempel/testmiljöer.

Anpassad lagring

På Orleans.EventSourcing.CustomStorage.LogConsistencyProvider så sätt kan utvecklaren ansluta sitt lagringsgränssnitt, som sedan anropas av konsekvensprotokollet vid lämpliga tidpunkter. Den här providern gör inga specifika antaganden om huruvida det som lagras är tillståndsögonblicksbilder eller händelser – programmeraren tar kontroll över det valet (och kan lagra antingen eller båda).

Om du vill använda den här providern måste ett korn härledas från JournaledGrain<TGrainState,TEventBase>, som tidigare, men måste även implementera följande gränssnitt:

public interface ICustomStorageInterface<StateType, EventType>
{
    Task<KeyValuePair<int, StateType>> ReadStateFromStorage();

    Task<bool> ApplyUpdatesToStorage(
        IReadOnlyList<EventType> updates,
        int expectedVersion);
}

Konsekvensprovidern förväntar sig att dessa fungerar på ett visst sätt. Programmerare bör vara medvetna om att:

• Den första metoden, ReadStateFromStorage, förväntas returnera både versionen och tillståndsläsningen. Om inget har lagrats än bör det returnera noll för versionen och ett tillstånd som matchar motsvarar standardkonstruktorn för StateType.

• ApplyUpdatesToStorage måste returnera false om den förväntade versionen inte matchar den faktiska versionen (detta motsvarar en e-taggkontroll).

• Om ApplyUpdatesToStorage det misslyckas med ett undantag försöker konsekvensprovidern igen. Det innebär att vissa händelser kan dupliceras om ett sådant undantag utlöses, men händelsen bevarades. Utvecklaren ansvarar för att se till att detta är säkert: t.ex. undvik det här fallet genom att inte utlösa ett undantag eller se till att duplicerade händelser är ofarliga för programlogik eller lägga till någon extra mekanism för att filtrera dubbletter.

Den här providern stöder RetrieveConfirmedEventsinte . Eftersom utvecklaren styr lagringsgränssnittet i alla fall behöver de naturligtvis inte anropa detta i första hand, utan kan implementera sin händelsehämtning.