Медленные операции в шаблоне Model-View-Presenter

Question

Как вы справляетесь с медленными операциями в Model-View-Presenter (или MVC или M-V-VM или любом другом варианте, который вы используете)?

Если у вас медленная работа в WinForms или SWT / JFace или любой другой платформе рабочего стола, которую вы используете, вы должны запустить ее в фоновом потоке, чтобы избежать полной блокировки приложения. Где вы справляетесь с этим?

Я вижу пару решений, но я не совсем доволен ни одним из них:

1. Пусть вызов представления всегда вызывает докладчика в фоновом потоке. Это означает, что представление должно обрабатывать то, что все вызовы от докладчика, вероятно, будут поступать из фонового потока.

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

Что вы обычно делаете?

РЕДАКТИРОВАТЬ: Я только что видел эту статью: http://www.codeproject.com/KB/threads/ThreadedExecuter.aspx. Это в основном реализация 2. Кто-нибудь пробовал что-то подобное?

Answer 1

Я использовал AOP , чтобы справиться с этим. Все вызовы методов просмотра перехватываются и синхронизируются с потоком пользовательского интерфейса. Мы настроили нашу платформу AOP (spring.net), чтобы сделать это для всех интерфейсов, которые наследуются от нашего IView базового интерфейса. На докладчиках мы используем атрибуты, чтобы указать, что эта медленная операция должна выполняться в фоновом режиме. Методы презентатора выглядят примерно так:

// ...
[RunInBackground]
public void TakeSomeTimeToRetrieveSomeItems
{
  var items = _svc.GetSomeItemsFromTheWeb();
  _view.ShowItems(items); // synced to UI automatically; blocks in presenter
}

По нашему мнению, нам не нужно делать ничего особенного:

// ...
public void ShowItems(IList<Item> items)
{
  itemBindingSource.DataSource = items;
}

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

Answer 2

Я использую довольно похожий подход к Tamberg (то есть, используя рабочие потоки для выполнения обработки).

Основным отличием является взаимодействие с представлением и моделью представления, которая содержит дополнительное состояние, с которым представление напрямую связывается для поведения, такого как:

• вход отключен
• обновления прогресса (довольно тривиально с использованием BackgroundWorker)
• уведомление о завершении

Поместив дополнительное состояние в модель презентации вместо представления, я могу поменять местами представления (или, как правило, два представления указывают на одного и того же докладчика).

Answer 3

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

пример:

class ServiceX {
     void doFoo(x arg , y arg2 , callback arg3){
          //do in your thread 
          arg3.success("with return variables you need")

          // or
          arg3.failed("with exception for example");

     }

}

interface Callback {
     void success(args...);
     void failed(args ...);
}


in your view :

// do 
ServiceX bar = // get your service

bar.doFoo(a1,a2,new CallBack(){
    void succes(args ...){
    }

    void failed(args ...){
    }
});

Answer 4

представление может вызвать ведущего из основного потока. Затем докладчик запускает операцию в рабочем потоке. И представление (например, с таймером) опрашивает докладчика из основного потока, чтобы предотвратить обратные вызовы в представление. С уважением, Тамберг