I am just starting porting an application to ASP.net MVC and I have an object holding application state (it keeps track of certain processes running on the machine, starting and stopping as necessary and sending/receiving MSMQ message).
Where should I keep this object? In my current application (based on HttpListener) it is a singleton, however I know singletons make testing difficult. It would be difficult to mock or test this object, at least in the context of the MVC application itself, and it has it's own set of tests outside the application anyway. However it may need to be replaced by a stub for testing.
The object needs to be made available to a number of controllers. Where should I store this object and how should I make it available to the controllers? I've never seen a case like this described in any ASP.net MVC examples I've seen.
UPDATE:
I guess I need to explain why I can't store this data in a database. First I must explain what the application does:
The application serves images that are generated dynamically by a number of "engines", which are processes running on the server, communicated to via MSMQ. Lets call the object I'm asking the question about the EngineManager. The process goes something like this:
- The client POSTs an XML request to the server, giving the name of "engine" to be used, as well as a number of parameters describing the image.
- The application checks the EngineManager to see if that engine is running. If not, it starts it.
- The application posts an MSMQ message to the engine and waits for the response.
- The application sends the generated image back to the client.
- If at any point the engine shuts down or crashes, the application must be aware of that so that it can be restarted on the next request to that engine.
- When the application shuts down, all engines are also shut down.
There are several controllers that handle these requests, each doing a slightly different job. All of them need to communicate with the same EngineManager, as it also needs to, in certain situations synchronise access to other resources.
As you can see, it's not your typical database-backed webserver.