Contents

• Getting Started
•     Overview
•     Video recordings about NServiceBus
•     Architectural Principles
•     Transactions
•     Building NServiceBus from Source files

• Samples
•     Web App Integration
•     Using NServiceBus with ASP MVC3
•     Encryption
•     Full Duplex - Request/Response
•     Generic Host - Logging
•     PubSub
•     Versioning
•     Message Mutators
•     Unobtrusive
•     Data Bus
•     Scale Out

• Day to Day
•     Dependency Injection
•     Support for child containers
•     Logging
•     Messages as Interfaces
•     Introducing IEvent and ICommand
•     Unobtrusive mode messages
•     Unit Testing
•     One way/Send only endpoints
•     Staying updated with NuGet
•     Scheduling with NServiceBus
• Hosting
•     In Your Process
•     NServiceBus Host
•     Profiles
•     More on Profiles
•     32-bit (x86) Host Process

• Management and Monitoring
•     Auditing
•     Monitoring
•     Msmq Information

• Scaling Out
•     Performance Information
•     Multi-Site with the Gateway
•     More about the Gateway
•     Multi-Server with the Distributor
•     Unit of work in NServiceBus V3
•     Unit Of Work implementation for RavenDB

• Publish-Subscribe
•     Overview
•     API and Configuration

• Long-Running Processes
•     Sagas

• Customization
•     Customizing Configuration
•     Pipeline Management Using Message Mutators

• Versioning
•     Migrating to NServiceBus 3.0 – Timeouts

Unit Of Work In NServiceBus

When using a framework like NServiceBus there is usually a need to create your own unit of work in order to avoid having to repeat code over an over again in your message handlers.
Examples would be committing NHibernate transactions, calling SaveChanges on the RavenDB session, etc etc.

In NServiceBus 2.6 your only hook into the message pipeline was the message modules, you can read about them in Jonathan Oliver's post.
This had some quirks since the HandleEndMessage method of the message module will be invoked regardless of the outcome and made it hard to decide if a commit or rollback should be performed.

In NServiceBus 3.0 there is a new way to do this, meet the IManageUnitsOfWork interface

public interface IManageUnitsOfWork
{
    /// <summary>
    /// Called before all message handlers and modules
    /// </summary>
    void Begin();

    /// <summary>
    /// Called after all message handlers and modules
    /// </summary>
    void End(Exception ex = null);
}

The semantics are that that Begin() will be called when the transport messages enters the pipeline, remember that a transport message can consist of multiple application messages. This allows you to do any setup that is required.
The End() method is called when the processing is complete and if there was an exception that exception will be passed into the method.
This gives you a way to perform different actions depending on the outcome of the message(s).

Where you should go from here?

The FullDuplex sample has an implementation of Unit Of Work, you can find it here.

Please read the Unit Of Work implementation for RavenDB.

This article was taken from Andreas Öhlund post that you can find here.