异步方法的“设计模式”是否良好?

时间:2011-07-08 22:46:52

标签: multithreading design-patterns asynchronous

当我编写一个包含可能会在另一个线程上执行的方法的类时,我准备我的类用于异步使用。 我将事件添加到类中,如下所示: methodProgressChanged methodCompleted

在方法中,在每个子操作(例如,迭代)之前,我使用自定义EventArgs类引发ProgressChanged事件。此自定义类包含有关现在开始的子操作以及上一个子操作的结果的信息。

因此,在另一个线程上执行该方法不是方法的任务,它只是报告进度。

当然,当我执行我的方法时,调用者负责订阅事件。

这个想法是否可以接受,还是我应该完全忘记?

2 个答案:

答案 0 :(得分:4)

如果您使用的是.NET 4.0,我建议您查看任务和任务以封装您的异步功能。然后你可以从你想要的方法返回一个任务,所以:

public Task<MyClass> Foo()
{
    return new Task<MyClass>(() => 
    {
         ReportProgress();
         DoSubOperation1();
         ReportProgress();
         DoSubOperation2();
         // ...
         return myClass;
    });
}

如果您不关心返回类型,则可以使用非通用任务。然后,当你调用Foo()时,可以在Task上调用ContinueWith,为它提供一个在Task完成后调用的方法。

如果您想要进步,则需要保留进度事件,因为这是您正在编写的方法的自定义。

但总的来说,Task是异步功能的一个很好的封装,可以让你不必一遍又一遍地重复相同的MyMethod()MyMethodCompleted()模式。

答案 1 :(得分:1)

这是一个合理的想法,但我认为这可能是过度的,只是因为你假设你的活动将被订阅。也就是说,只要您的活动订阅者行为正常,我认为这不会导致太多问题。只是这样做会产生一些可能浪费精力的开销。也就是说,除了(添加/提升事件)的(少量)(可能没有用的)时间之外,我并没有真正看到任何错误。