2010-02-03 2 views
1

Я смотрел на Prism EventAggregator и его «отличный». В большей части меня больше всего интересовала его способность правильно направлять поток к потоку UI.Может ли Prism EventAggregator использоваться для потоковой обработки?

Мне было интересно, могу ли я использовать эту возможность, чтобы предоставить разработчикам модулей класс, который может быть использован для создания потоков аналогично BackgroundWorker. Интерфейс класса может быть несколько похож на

public interface IMyTask 
{ 
    event DoWorkEventHandler DoWork; 
    event RunWorkerCompletedEventHandler RunWorkerCompleted; 
    void RunTaskAsync(object obj); 
} 

Я сохранил типы, похожие на фонарика, для лучшего понимания. При реализации я регистрация TaskStart и taskcomplete события

public class TaskStartEventPayload 
{ 
    public SubscriptionToken token { get; set; } 
    public object Argument { get; set; } 
} 

public class TaskStartEvent : CompositePresentationEvent<TaskStartEventPayload> 
{ 
} 

public class TaskCompleteEventPayload 
{ 
    public SubscriptionToken token { get; set; } 
    public object Argument { get; set; } 
    public object Result { get; set; } 
} 
public class TaskCompleteEvent : CompositePresentationEvent<TaskCompleteEventPayload> 
{ 
} 

В конструкторе для класса MyTask я взять какой поток завершения требуется в качестве

public MyTask(IEventAggregator eventAggregator, bool isUICompletion) 
{ 
     if (eventAggregator == null) 
     { 
       throw new ArgumentNullException("eventAggregator"); 
      } 
      _eventAggregator = eventAggregator; 
      _eventAggregator.GetEvent<TaskStartEvent>().Subscribe(TaskStartHandler, ThreadOption.BackgroundThread, false, new Predicate<TaskStartEventPayload>(StartTokenFilter)); 
      if(isUICompletion) 
       _token = _eventAggregator.GetEvent<TaskCompleteEvent>().Subscribe(TaskCompleteHandler, ThreadOption.UIThread,true,new Predicate<TaskCompleteEventPayload>(CompleteTokenFilter)); 
      else 
       _token = _eventAggregator.GetEvent<TaskCompleteEvent>().Subscribe(TaskCompleteHandler, ThreadOption.BackgroundThread, true, new Predicate<TaskCompleteEventPayload>(CompleteTokenFilter)); 
     } 

здесь я регистрирующий с фильтрами, где функция фильтра возвращает событие, только если у него есть полезная нагрузка, имеет тот же токен, что и во время подписки.

далее я использую

public void RunTaskAsync(object obj) 
{ 
    //create payload 
    _eventAggregator.GetEvent<TaskStartEvent>().Publish(payload); 
} 
public void TaskStartHandler(TaskStartEventPayload t) 
{ 
    //fire dowork and create payload 
    DoWork(this, args); 
    _eventAggregator.GetEvent<TaskCompleteEvent>().Publish(tc); 
} 
public void TaskCompleteHandler(TaskCompleteEventPayload t) 
{ 
    RunWorkerCompleted(this, args); 
} 

Этот класс может быть использован в качестве

 MyTask et = new MyTaskagg, true); 
     et.DoWork += new System.ComponentModel.DoWorkEventHandler(et_DoWork); 
     et.RunWorkerCompleted += new System.ComponentModel.RunWorkerCompletedEventHandler(et_RunWorkerCompleted);    
     et.RunTaskAsync("Test"); 

Benefit Я вижу в этом подходе является 1. использует Threadpool поэтому никаких накладных расходов создания потоков, как в BackgroundWorker. 2. Правильная сортировка потоков в случае, если RunWorker завершен для выполнения в потоке пользовательского интерфейса.

Прошу совета, если было бы правильно использовать eventaggregator как Threader.

ответ

1

Это будет работать, хотя это код, который вы должны отлаживать для очень небольшого прироста производительности. По моему мнению, микрооптимизация редко стоит усилий и вспомогательных расходов.

EventAggregator предназначен для передачи сообщений для вашего приложения, и я обычно предпочитаю использовать вещи для их первоначального намерения, чтобы мне не пришлось отлаживать много кода, но это мои личные предпочтения.

Агрегатор событий должен работать немного сложнее, чем он предназначен для очистки всех этих подписчиков, что, вероятно, превысит любое увеличение производительности, получаемое от объединения потоков, но это всего лишь предположение.