Question

I am working through the first steps of figuring out Nservicebus and planning a reasonably large scale (at least for me) app.

I want the app to be able to scale out onto X machines. It will have a number of services, such as:

LogonService
UserManagementService
GameService
RoomService
etc…

The clients would talk to the server through WCF. The services themselves would talk to each other via NServiceBus and MSMQ. Sacha Barber has written an excellent article on getting started with NServiceBus and has come up against the same situation I am going to hit. There is a further chat between Udi and Sacha about this here.

My Question is, when a service is handling a message how does it know about the rest of the app in that service? As Sacha puts it, “a handler will automagically” appear when a message needs dealing with. So when this is created how does it know about the other objects that are already up and running. For example in the GameService, it would have a list of all games currently running. How would it access this?

I guess the two options that I can think of, (as Sacha pointed out), are:

Mediator pattern
Singleton

Out of the two I think I would rather register a singleton with Castle Windsor and use it that way.

Is this an appropriate use of the Singleton pattern, (as you often see people referring to the Singleton as the “Devil”, I don’t want to miss use it if possible).

Is there a better solution to this problem?

Thanks

Answer 1

For state that need to be kept in memory I would also use the Singleton pattern. Otherwise state is usually maintained in the datastore and read by the handler for each message proceed.

public Handle(SomeMessage msg)
{
   var aggregateRoot = writeStore.Get(msg.SomeId);

   aggregate.DoSomeAction(msg.SomeOtherData);

   //if write store does not support dirty tracking
   writeStore.Save(aggregateRoot);
}