GitXplorerGitXplorer
r

NServiceBus.InjectStorageContext

public
2 stars
3 forks
7 issues

Commits

List of commits on branch master.
Verified
14391c56417d808609abf6b802e02f46f4bcdd09

Enable dependabot

rramonsmits committed 3 years ago
Verified
db578b97d26c7f3e24dfbc9c9f5fe0d0247e2881

Update dependabot.yml

rramonsmits committed 3 years ago
Unverified
113be85ddc6a513db647c039c525ea542607c34e

Merge branch 'v7'

rramonsmits committed 3 years ago
Unverified
a5113cbe4e13a39dff4d1f82518d0b608c1c7677

Upgraded packages and code to resolve warnings.

rramonsmits committed 3 years ago
Verified
3c6dc44287b9725853422139f6dc4d8d0504e101

Upgrade to GitHub-native Dependabot

ddependabot-preview[bot] committed 4 years ago
Verified
33561267ba3492c9b462139e46824afbf510691c

Note on v6

rramonsmits committed 7 years ago

README

The README file for this repository.

Note: This is the v7 version, check the v6 branch for a v6 version.

Sample: Inject Storage Context with DI

In NServiceBus 5 the NHibernateStorageContext storage context was registered in the container. In NServiceBus 6 this does not work anymore because the context is not registered in the container and cannot be injected via the constructor any more. It can only be passed as an argument meaning you have to pass the context as argument into the IOrderRepository.Add(Order) which is - obviously - not what you want if you use the repository pattern. This sample extends NServiceBus with behavior very similar to NHibernateStorageContext which was available prior to NServiceBus 6.

Solution

The pipeline is extended with a StorageContextBehavior behavior. It resolves the storage connection and transaction objects as would be needed in a regular V6 handler via the just before the handlers are invoked and assigns the values to the by the container created StorageContext object. The StorageContext object is registered as DependencyLifecycle.InstancePerUnitOfWork and the repository OrderRepository repository is dependant on it. When the handler object graph is created by the container, all potential repository objects will share the same StorageContext object instance. This way all created repository objects or any other object that would take a dependeny on StorageContext can now access the shared IDbTransaction and IDbConnection to make sure all queries participate on the same connection and unit of work.