Skip to content

Getting started

Tomas Lycken edited this page Oct 2, 2017 · 19 revisions

The RdbmsEventStore has a few common components, and a few components specific to the backing database engine.

The Event Registry

In order to keep track of your event types, and to handle serialization and deserialization of event payloads, you must build an event registry for your events. In its simplest form, it is just a bi-directional dictionary between strings (event names) and System.Types (event types). In most common use cases, you can use an AssemblyEventRegistry, that does a lot of the work for you:

var eventRegistry = new AssemblyEventRegistry(
    typeof(SomeEventType),
    type => type.Name.EndsWith("Event"));

The predicate is optional, and only types for which it returns true are added to the registry.

The Event Factory

RdbmsEventStore is extensible, so that you can create your own event type and add whatever metadata you need. Therefore, the implementation depends on having an event factory available, which will take your event payloads, serialize them, add metadata and return an instance of the event type you'll persist. In most cases, though, you'll be fine with an event type that's just a plain implementation of the IEvent<TId> interface (the generic type parameter is the type of the event and stream ids), and for that case the default event factory will be enough:

var eventFactory = new DefaultEventFactory(eventRegistry);

The Write Lock

In order to ensure that you don't have multiple threads adding events simultaneously, your event store should depend on the write lock. There is an interface IWriteLock and a default implementation WriteLock that just wraps an AsyncLock from Stephen Cleary's AsyncEx suite:

var writeLock = new WriteLock();

Using Entity Framework 6