What is the purpose of the "View" in the Model-View-Presenter pattern?

I understand the general reason why the Model-View-Presenter pattern is a good pattern. It separates the concern so that the same parts of code that deal with presenting in开发者_JAVA技巧formation to the user do not worry about calculations, etc. My quesion is why do we need a view that essentially does nothing? All the view does is tell the presenter to do work and get the result back from the presenter. For example, in my C# views, I often just have a bunch of event handlers that call delegates that are implemented in the presenter. Why not just combine the view and the presenter? No concern is really separated because the view does not have any concern.

---

Two important advantages

• We can write multiple views or replace views easily (for example WinForms => WPF implementation)

• We increase the testability by creating test views for unit tests

---

Your View should simply be a way to get data to and from the user. Anything else that is not specifically related to that functionality should be pushed down into the Presenter (or model if it needs be). The presenter handles what the view gets but it should never be concerned with what view does once it gets it.

The presenter is an attempt to look at your "UI" in a more semantic manner. You may have 2 textboxes on your View but your Presenter sees Name and Surname. The idea should be that with the minimal amount of fuse you could lift the View off an pop another one on.

I don't know how much I agree with that and tend to prefer MVVM where you don't have Presenters, instead you have ViewModels which I feel are a better way to define the above abstraction.