views:

405

answers:

2

I am working on a winforms project. I am implementing an MVP architecture. I have some processing intensive jobs running at the presenter (Reading from file system and performing bulk inserts to a DB). I would like to perform these operations in a background thread without locking up the UI and update controls on my view (progress bar, and datagridview).

Should I just access the backgroundworker object within my presenter and handle it's events in the presenter by having the view event handlers trigger events that the presenter is listening to??

For example:

In the VIEW:

private void backgroundWorker_ProgressChanged(object sender, System.ComponentModel.ProgressChangedEventArgs e)
        {
            if (WorkerProgressChange != null)
        {
            WorkerProgressChange(this, EventArgs.Empty);
        }
    }

In the Presenter:

_view.WorkerProgressChange += UpdateView;

Does this seem reasonable? Can someone offer a better model?

Thanks!

A: 

I think the view should be as passive as possible. The presenter should handle itself the events from the BackgroundWorker and translate this information to the view (e.g. update a list shown in a grid). To the view, this request should be no different than if the data had come directly from the presenter.

Timores
Right.. So just subscribe to the backgroundworker's events within the presenter. Don't know why I thought I had to use the event handlers that the designer creates. I will just blow them away.
Nick
+2  A: 

Work should not be summoned by the presenter - add another model unit that does the work and call the work (can be via the gui) from the controller.

(Have the view raise a Work event, handled by the controller, which summons the backgroundworker and calls the view on updates/completion).

Danny Varod