Separation of GUI and logic in different threads in a Windows Form application

Question

In a Windows Forms application I want to separate the GUI from the logic. The user requests are complex and involve communications so I don't want it to depend on the GUI thread. The structure should be something like:

        GUI -----> splash screen ---------> User Form --------------> ...
              |                        #
              | create Manager thread  | Show this Form
              #                        |
    Manager -----> Check user type -------> Wait for user command --> ...

Which are your advices, guidelines or patterns for a design like this one? Is it the correct choice? Thank you!

EDIT The Manager thread should control the GUI and not in reverse. Moreover, the Manager thread should live during all the application time.

Answer 1

Traditionally work like this is done using a BackgroundWorker

Basically it is a simple class that gives you the ability to perform a function on a worker thread and then will automatically invoke back to the UI thread after that function is complete. During the time that the function is being run the UI is unblocked and can display a progress message, or process other user input (cancel for example).

The result is similar to your pattern, but a separate thread is created and destroyed (well, there is pooling really...) for each task.

UI thread ---> Show splashscreen------------------->Show window-------
                      |                           |return to UI      |
                      | create background worker  |                  |
                      -> Process user ------------                   ->Perform query etc.

---

Okay, based on your comment:

You can use a pattern like that, it is a simple case of eventing. Give the UI access to your manager so that it can perform a method call on it and register for events when the task is completed (this link shows the two major patterns for async operations in .NET). Inside the manager you'll need to maintain a list of tasks that can be performed in sequence on the single thread and ensure that the events that are called to return the results to the UI are properly invoked so that are run on the main UI thread (basically recreate the background worker pattern).

I'm not sure what you are hoping to gain by doing this, is there a reason the application needs to be limited to two threads? Are you concerned about the cost of creating backgroundworkers? Do you need some kind of query queue system? The examples in the diagram in your question don't seem to require the complexity of this kind of pattern.

Answer 2

You should use a background worker to complete your task.

It has events that will be very handy. DoWork and RunWorkerCompleted, which will come in very handy.

You can also try using Threads, They will look something like this: (Bear in mind, when you use Threads, if you want to do any work with the UI Thread, you must Invoke(), otherwise you will received a CrossThreadException)

private delegate void MyFunctionCaller();

//This will set up your worker thread and set it off
private void SetThreadToDoWork()
  {
  ThreadStart threadStart = new ThreadStart(DoWork);
  Thread MyThread = new Thread(threadStart);
  MyThread.Start();

  ShowSplashScreen();
  }

private void DoWork() 
  {
  DoMyWork();
  WorkCompleted();
  }

private void WorkCompleted()
{
if (InvokeRequired == true)
  {
  MyFunctionCaller InvokeCall = delegate { WorkCompleted(); };
  Invoke(InvokeCall);
  }
else
  {
  //Back to the UI thread now.
  }
}

OPs Edit

You can create the thread wherever you like, once it has started you can have it completing several functions. But keep in mind that you need to Invoke() if you want to complete any work that the UI Thread can only complete otherwise you will get a CrossThreadException.

Answer 3

I've developed a similar project. GUI launch the manager on a different Thread. Manager have some method to get commands from the GUI. GUI is listening to Manager's events, so it's updated only when Manager raise up an event. To avoid crossthreading, i used to "Invoke" methods