 <p>The View component must contain sufficient logic to display the interface to the user. Depending upon the framework used, there can be quite a bit of code in the View. The important thing is to ensure <em>business logic</em> lies in the Presenter.</p> <p>Regarding your secondary query, all Presenter methods will be invoked on the EDT when the View calls them (in the case of Swing). Unless the action required by the Presenter is trivial, I would immediately kick off a background thread to complete the work. That thread will update the View when completed using <code>SwingUtilities.invokeLater()</code>.</p> <p>In fact, to avoid being tied to Swing, I tend to pass my own <code>EventDispatcher</code> class to each Presenter. This is an interface with the same methods as <code>SwingUtilities</code>. I can then substitute in a different class if necessary.</p> <p><em>Side note: this can make unit-testing the Presenter with JUnit difficult, because the Presenter method (and the unit test) will complete before the background thread does. I tend to construct each Presenter with an <code>Executor</code> that is responsible for running the background threads. Then, in a unit test environment, I pass in a special <code>Executor</code> implementation that immediately executes the <code>run()</code> method on the same thread. This ensures the unit tests are single-threaded. Example:</em></p> <pre><code>public class SingleThreadExecutor implements Executor { @Override public void execute(Runnable command) { command.run(); } } </code></pre>