interface ISomeView : IView
Username{ get; }

-c

Do you really expose a setter for View’s fields like UserName? From the article I understood that view updates itself in UpdateYourself(UserPreferencesPresentationModel model) method. Keeping in mind that PresentationModal could have some logic, exposing a setter for View’s element could bypass this [ tested ] logic.

There are a few ways, but the one I’ve usually ended up using was to expose properties on the IView interface (i.e. Username{ get; set;}) that the Presenter can grab off its IView reference.

and call this method inside event handlers, like ResetPasswordClicked?

Gary Brunton asked the same thing much earlier in the comments.

Also could you extend the code to show how the controller would be implemented in terms of business state. I’m curious about state with webforms and what you think a good way to load, maintain/calculate, and save the data. Is it in the controller, is in a business service, is in business entities, etc.

I like the practical example so far!

You might also have a few integration tests between the Presenter and the View, but the idea of PM is to limit the interaction between the two. The view might just expose a bunch of properties (state) so you could just stub it and the view just calls methods on the presenter (Hey! this button was clicked!)

Assert.IsTrue(_presentationModel.PasswordDisabled);

or (using Scott Bellware’s SpecUnit.NET testing extension methods)

_presentationModel.EditingAllowed.ShouldBeTrue();

A full test might be like this:

[Test]
public void editing_should_be_allowed_after_entering_edit_mode()
{
var theView = MockRepository.CreateStub();
var presenter = new SomePresenter(theView);

presenter.EnterEditMode();

presenter.Model.EditingAllowed.ShouldBeTrue();
}

(1): If you’re using WinForms, Can’t you use some of the various data binding options? Aside from that, I don’t think it’s too big of a deal to re-set the values on all the textboxes and such. You might have to be judicious about when lists or grids are updated in which case you could have a flag or something on the presentation model that lets the view know that there’s new data available and it should rebind. There are a few options here. No, you don’t HAVE to rebind everything all the time if that’s not appropriate. There are a few options: Having multiple UpdateYourself() methods that take smaller subsets of the presentation model (PM), Have the ability to compare the previous PM state to the new PM state and produce a difference set of changes.

(2) The point of PM is to make it easier. The PM does not need to be mocked since it is purely state. State-based testing is much easier than mocking/interaction testing and it makes it easier to test the state coming out of the presenter as well as how the view reacts when to new state coming in.