After having some difficult hours mulling over some architecture issues for my server-based application, I feel I am going to have to use singletons to accomplish my goal. Purely for the following reasons (justifying my smell):
- I don't need to pass expensive objects deep into a call stack
- I can perform functions on singleton management objects within any context. (A lot of the code already exists and therefore I am unwilling to rewrite extensive chunks of otherwise working code)
Apart from that, Singletons suggest another problem. My server-based application is essentially a DLL with a class that can invoke multiple instances of servers. The server instance class contains the singleton management objects. Ordinarily, this would be managed by a Windows Service, so server:machine ratio will be 1:1.
So you could view it as (where -> is 1:1, => is 1:many):
MACHINE -> ServiceHost (Windows service?) -> Server instance -> Singleton management objects
However, we would like to allow for an SaaS model, which would require a service host (be it a Windows Service or Win32 application) to be able to fire up multiple servers as required by the business. Therefore, a physical machine could run a single server host, which would run multiple server instances.
Which would be (where -> is 1:1, => is 1:many):
MACHINE -> ServiceHost (Windows service?) => Server instance -> Singleton management objects
The problem is that these singletons would be shared across servers. Which cannot happen. The singletons must be 1:1 with the server instance.
Assuming I cannot move away from these singletons, is it possible for me to separate these server instances from each other by invoking the service instance class as a separate process/memory space?
I can only imagine that I would need to fire up multiple EXEs (anduse WCF to manage), one for each server instance. This would obviously not be very good.