Make your views stupid
April 11th, 2008
I’ve been working on a project that is using a Model-View-Presenter pattern. I’ve noticed something in the view code that I want to write a quick post about: views that are way smarter than they should be.
The presenter represents the workflow or process that the user is working on. It encapsulates the state of a use case instance. It has the responsibility of responding to the user’s interaction. The view simply displays data and sends messages back to the presenter when the user interacts with an element in the view.
If you have code like this in your view:
| // some button click event handler |
| presenter.DoSomething(); |
| presenter.RefreshTheView(); |
then you have a bad smell. It should look like this:
| // some button click event handler |
| presenter.DoSomething(); |
| // presenter’s code |
| public void DoSomething() |
| { |
| // build a request from the view data |
| // do something |
| // refresh the view |
| this.RefreshTheView(); |
| } |
Unless you have a lot of formatting to do in the view, your view should be comprised of a lot of one line method calls back to the presenter (or preferably raised events). The presenter should tell the view “show this to the user” and, optionally, “action XYZ is not available”. The view should tell the presenter “the user did something”. I like to specify this as events on the view interface so the complete communication contract is documented in one spot – but that’s another post.
Sorry, comments are closed for this article.