Add Saga Persistence Configuration to AddMassTransit registration
See original GitHub issueCreate extension methods for the registration configurator (invoked via the .AddMassTransit
container extension method) for the supported saga repositories so that they can easily be configured for the configured sagas (including state machine sagas).
This would configure the persistence components in the container so that they are properly resolved as the endpoints are configured. Should support an easy way to say “for all my sagas, use this” and let the registration sort it out (generics, vs explicit registrations, etc.).
Storage Engines
- In Memory
- NHiberate
- Entity Framework
- MongoDB
- Redis
- Marten
- DocumentDb
- Dapper
- Azure Session State
Documentation
- Consistent example stage machine and instance, following Automatonymous example
- Top level introduction to the registration syntax
Bonus Features
- Use a bus observer to connect/disconnect database connections for saga repositories when the bus is started/stopped, so that a failing connection might stop the bus from starting.
Repository Changes
Migrate the existing implementations to a new set of saga repository interfaces.
ISagaRepositoryContextFactory<TContext>
Used to created a SagaRepositoryContext<TContext> for each received message.
ISagaConsumeContextFactory<TContext, TSaga, TMessage>
Used to create a SagaConsumeContext<TSaga, TMessage> for a saga instance that has been loaded from storage or created by an initiating message.
ISagaRepository<TSaga>
Should remain mostly unchanged, but would have a standard implementation that uses the above interfaces to manage the repository interaction and focus purely on the saga behavior details (and dry up the saga repositories).
ILoadSagaRepository<T>
and IQuerySagaRepository<T>
These are now consistent and supported by storage engines that have query and/or load support, and used by the unit testing extensions where available.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:23 (23 by maintainers)
I think it will need to match whatever the built-in support is for the framework. If it’s EF, I think something like:
Basically give the same configuration extensions support that EF uses just start it with a different preample.
I’d like user to explicitly provide repo for a saga