Extending MVP: Roles and Responsibilities

The system starts with Model classes. Model classes contain data, and all business rules which govern the handling of the data. No business rules should exist outside of model classes, and models should in no way be coupled to UI elements or infrastructure. Models must have well-defined public interfaces. Models communicate with infrastructure to manage things like persistence, printing, or other hardware interaction, but they do so through well defined interfaces that provide separation so that the models can be unit tested. Models may call methods on infrastructure classes, but may only communicate upwards (to the UI) through events.

Connecting models to the UI are presenter classes. Presenters contain no logic, and serve only as the connection between the model and the view interface. Presenters are passed a model and a view interface and can either hook up events directly, or respond to events themselves by calling methods. I prefer the latter solution as it allows models and views to be completely de-coupled, whereas with the former they must at minimum share delegate signatures. Presenters always have exactly one view and one model. Presenter handle events fired by models and views, and call methods on models and views.

View interfaces should contain no direct references to actual GUI widgets. Views should contain methods like ShowPrompt, and events like QuantityEntered, rather than exposing labelPrompt.Show or textBox.Text directly. Views can be instantiated by winforms, webforms, or any other UI technology.


Next I will discuss Workflow manager and transaction manager classes.