• View is composed by web form or user control.
• View *at most* only contains UI logic.
• View propagate each page events to the Presenter.
• View uses Data Binding for hydration.

• Presenter contains complex application logic.
• Presenter interacts with models and views.
• Presenter access the View through an intermediary which act as a Gateway

• Model contains data and business logic.

Versus MVC Framework

+ still have page events (depending on how one look at it, this could be a negative too)

+ lower learning curve

+ not relying on pre-released framework


- View still have a huge role in application logic

- a more intimate bind between View and Presenter than in MVC framework

Example
[edit 13-April-2009] The example below is using Model View Presenter/Passive View, where the view doesn't know anything about the model.
Notice that I'm passing all the bindings using native types and calling the appropriate properties in the view.

View

// this interface will be adapted by the webform and testing stub/mock
public interface IShowMonkeyView
{
	string Id {get;}
	string Name {set;}
}

// webform
public partial class ShowMonkeyView : Page, IShowMonkeyView
{
	private MonkeyPresenter presenter;

	//constructor
	public ShowMonkeyView()
	{
		// inject the view to the presenter
		presenter = new MonkeyPresenter(this);
	}
 
	//page event
	public void ButtonClicked()
	{
		// propagate page event
		Presenter.ShowMonkey();
	}
	
	public string Id { return Request.QueryString("Id"); }

	// intermediary - databinding gateway
	public string Name { txtboxName.Value = value; }
}

Presenter

public class MonkeyPresenter
{
 
	private IShowMonkeyView view;
 
	//inversion of control constructor
	public MonkeyPresenter(IShowMonkeyView _view)
	{
		view = _view;
	}
 
	public void ShowMonkey()
	{
		// interact with Models
		IMonkey daMonkey = Monkey.Find(view.Id);

		// hydrate view
		view.Name = daMonkey.Name;
	}
}

References
Martin Fowler. Supervising Controller.