I am developing a desktop application that will be run at each station at a call center. It listens for an incoming call, and whenever a call arrives, there are about 30 different classes that need to run various operations. Some of these operations are synchronous, such as setting a flag because they want to log only the first time per call that an event happens. Some of them are asynchronous, such as establishing a socket to another application and sending a start message. At the end of the call, the classes will also have to do some clean up, such as sending an end call message, awaiting a response, and then closing the socket.

Currently, I create all the classes in the composition root, and they live for the life of the application. Each time a call arrives, the state of all of these classes gets reset. Here is a simplified, but working, code sample:

My problem is that this seems kind of fragile. The order in which the objects is started becomes very important, especially if the objects are related. Otherwise you can run into a situation where SocketConnection is feeding messages to MessagePersistence, which hasn't yet completed its startup. This prevents doing something like running the tasks in parallel.

I feel like it would be better to create these objects as needed, so they can never be in an invalid state. In other words, the call started event would call a factory method to asynchronously create objects. That way, the MessagePersistence dependency passed to SocketConnection will be guaranteed to be in a valid state for receiving messages before SocketConnection is even created.

So my thought would be to make an abstract factory like the following:

The call started event handler would call the factory method to get a collection of IAsyncDisposables, which it would save in a shared data class injected into it. The call ended event handler would also be injected with this shared data class and could just go through all of them and call DisposeAsync to do the cleanup.

Does this technique make sense? I'm used to a factory creating one instance of an object. Is it weird to have a factory that creates a bunch of objects and returns all of them in a collection? Or is that overkill and things are fine the way they are? Or maybe there is some cleaner way that I'm missing? I'm using C# 6.0 if it matters.