C# BackgroundWorker thread writing to Excel 2007 via server sending messages

I would appreciate some views on the following design:

I have a server that constantly send messages which I wrote a C# assembly to subscribe to. Currently, whenever there are any messages sent, I will write it asynchronously to ms Excel 2007. As this is a resource heavy process, I have used a backgroundworker thread to handle the connection to the server and receive the messages before writing to excel.

public static void bw_DoWork(object sender, DoWorkEventArgs e)
    {
        //This method will establish conn to server, and subscribe to the messages sent asynchrously.
        //After which, cre开发者_如何学JAVAateSpreadsheet(String msg) will be called to write the message to excel
        runMsgServerConsumer();

    }

Question: Is this a good design? Alternatively, I have though of letting the main thread establish the conn to server and let the backgroundworker thread handle the writing to excel via the createSpreadsheet(String msg).

I suspect it won't make much difference, especially if Excel is being automated in visible mode and is continually redisplaying all those cells with new data in them, displaying graphs etc. COM automation is pretty heavy anyway and surely swamps any loading from subscribing to the server thread that receives the data. One reason for decoupling the data receipt from the Excel calls might be that your input data tends to arrive in heavy bursts, in which case a queued link between two threads would improve performance, and perhaps load as well since more cells could be written in one Excel call, (not sure about this - you need to try it).

I have used this kind of app for analysing/displaying test results on a telecomms system. It worked OK. I threaded off the data source and ran the automation in the main thread, communicating the data with PostMessage, (all Delphi unmanaged code). Not tried it in C#.

Can you easily just test this & see if the load/performance drops?

Rgds, Martin