Home/ Questions/Q 9159945
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T13:37:02+00:00

We’re using NServiceBus and Ninject for a multi-tenant SaaS application. When the user is

  • 0

We’re using NServiceBus and Ninject for a multi-tenant SaaS application.

When the user is accessing our web site or API we can determine which account the user is connected to by examining the host name of the HttpContext Request object, retrieving various settings about the account (one of which is the database we should connect to) and the rest of the request is connected to the correct database (various other checks take place).

In our NSB Windows service we don’t have that concept of a shared context by which we can determine the host database to connect to so we’ve created a property on our base command classes that stores the account/database who created the command/message.

When the message handler is constructed for the incoming message, one of the dependencies is a repository that takes the name of the database it should be connecting to as an argument.

As said before, Ninject can access the correct DB in the HttpContext for web requests but for the NSB service the message itself contains the DB details which we can only access after the handler is constructed, which obviously fails as it requires an argument (which is contained within the message!) to successfully construct the repository. Chicken and egg 🙂

This is a long winded way of asking…

  • Is there anyway to access the properties of a message during the Ninject creation cycle?
  • This feels like one of those hard problems that’s hard because my architecture is ‘wrong’, is that the case?
  • I want to avoid putting a public property on a repository like “SetDatabase” as that feels like it could be easily abused/misunderstood and cause havoc with users data.
  • I’d also thought about creating a repository factory, that Ninject would use but still not sure how to access the incoming message properties.

Thanks in advance!

Edit for solution

I ended up using a hybrid approach from the answers from Udi and Eben.

I used an out going message mutator for my API messages that added the account name of the customer to the headers (from the HttpContext) of the outbound message.
Then, in the NSB Windows service I used an inbound mutator to examine the headers and extract the account name, as suggest by Udi.

I also created two instances of an interface that provided the connection string / account details to my repositorys as suggested by Eben. One to be used in web requests and one ThreadStatic type to be set by the incoming mutator and then Ninject bound to be used for repo instantiation for NSB.

I can’t mark both as correct , sorry Eben!:)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You should look at using the unit of work or message mutator hooks for doing that kind of work. More info here:

    http://support.nservicebus.com/customer/portal/articles/860275-unit-of-work-in-nservicebus

    http://support.nservicebus.com/customer/portal/articles/860492-pipeline-management-using-message-mutators

    I’d also recommend using headers on your messages for that kind of information rather than putting it on a base class.

    • 0