Long-running tasks are usually executed in a background thread to keep the UI from freezing. It seems the threading logic could reside in either the view or in the controller.
As an example (in C#), suppose there is a method named RunAsync
that runs a delegate in a background thread, here are two ways of doing it:
// Option 1
public class View {
public void OnButtonClicked() {
RunAsync(() => controller.DoSomething());
}
}
public class Controller {
public void DoSomething() {
model.Foo();
}
}
or:
// Option 2
public class View {
public void OnButtonClicked() {
controller.DoSomething();
}
}
public class Controller {
public void DoSomething() {
RunAsync(() => model.Foo());
}
}
Is there an advantage to doing it one way or the other?
In my opinion, it should be handled by the Controller. Since you want to separate the Model from the View as much as possible, really the View should have no idea that a particular call such as
model.Foo()
takes a long time and therefore needs to be run asynchronously. The Controller on the other hand is the only one that really has knowledge of both, and therefore should make the decision on whether some operation needs to run asynchronously.My understanding is Controller( or ViewModel in WPF) should handle this. View is always intended to be coupled with 'VIEW' related stuffs, thus tasks like running background job should go to controllers.
doesn't that sound odd to you that VIEW should handle this logic ?
I see two arguments for the Controller having the responsibility for Thread safety.