在Windows窗体应用程序，我想在GUI从逻辑中分离出来。用户要求复杂，涉及通信，所以我不希望它依赖于GUI线程。该结构应该是这样的：

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!

修改 该管理器线程应控制GUI而不是相反。此外，该管理器线程应该在所有的应用程序的时间生活。

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

推荐答案

传统上这样的工作完成的。 backgroundworker.aspx相对=nofollow> BackgroundWorker的

Traditionally work like this is done using a BackgroundWorker

基本上它是一个简单的类，让你在工作线程执行功能的能力，然后会自动调用回UI线程后功能齐全。在此期间，该功能被执行的UI是畅通并且可以显示进度消息，或处理其它用户输入（取消例如）。

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.

好了，根据您的评论：

您可以使用这样的模式，它是事件触发了一个简单的例子。给你的经理用户界面的访问，以便它可以在其上执行一个方法调用，并注册事件，当任务完成后（的这个链接显示了两大模式在.NET异步操作）。经理在里面你会需要维护，可以在序列上的单个线程中执行的任务列表，并确保被称为返回结果给UI事件是否正确调用，以便在主UI线程上运行（基本上是重新创建后台工作模式）。

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).

我不知道你希望什么获得通过这样做，是有原因的应用程序需要被限制在两个线程？你关心创建backgroundworkers的费用是多少？你需要某种形式的查询排队系统的？在你的问题在​​图中的例子似乎并没有要求这种模式的复杂性。

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.