The Model View Presenter (MVP) pattern is very similar to MVC. It is a fairly well known pattern in the Microsoft world and is generally used to structure WPF and Silverlight applications. It can be used in pure JavaScript as well. The key difference comes down to how the different parts of the system interact and where their responsibility ends.
The first difference is that, with the presenter, there is a one to one mapping between presenter and view. This means that the logic that existed in the controller in the MVC pattern, which selected the correct view to render, doesn't exist. Or rather it exists at a higher level outside the concern of the pattern. The selection of the correct presenter may be handled by a routing tool. Such a router will examine the parameters and provide the best choice for the presenter. The flow of information in the MVP pattern can be seen here:
The presenter is aware of both the view and the model but the view is unaware of the model and the model unaware of the view. All communication is passed through the presenter.
The presenter pattern is often characterized by a great deal of two-way dispatch. A click will fire in the presenter and then the presenter will update the model with the change and then the view. The preceding diagram suggests that the input first passes through the view. In a passive version of the MVP pattern, the view has little to no interaction with the messages as they are passed onto the presenter. However, there is also a variation called active MVP that allows the view to contain some additional logic.
This active version of MVP can be more useful for web situations. It permits adding validation and other simple logic to the view. This reduces the number of requests that need to pass from the client back to the web server.
Let's update our existing code sample to use MVP instead of MVC.
Let's start again with the view:
class CreateCastleView {
constructor(document, presenter) {
this.document = document;
this.presenter = presenter;
this.document.getElementById("saveButton").addEventListener("click", this.saveCastle);
}
setCastleName(name) {
this.document.getElementById("castleName").value = name;
}
getCastleName() {
return this.document.getElementById("castleName").value;
}
setDescription(description) {
this.document.getElementById("description").value = description;
}
getDescription() {
return this.document.getElementById("description").value;
}
setOuterWallThickness(outerWallThickness) {
this.document.getElementById("outerWallThickness").value = outerWallThickness;
}
getOuterWallThickness() {
return this.document.getElementById("outerWallThickness").value;
}
setNumberOfTowers(numberOfTowers) {
this.document.getElementById("numberOfTowers").value = numberOfTowers;
}
getNumberOfTowers() {
return parseInt(this.document.getElementById("numberOfTowers").value);
}
setMoat(moat) {
this.document.getElementById("moat").value = moat;
}
getMoat() {
return this.document.getElementById("moat").value;
}
setValid(validationResult) {
}
saveCastle() {
this.presenter.saveCastle();
}
}As you can see the constructor for the view no longer takes a reference to the model. This is because the view in MVP doesn't have any idea about what model is being used. That information is abstracted away by the presenter. The reference to presenter remains in the constructor to allow sending messages back to the presenter.
Without the model there is an increase in the number of public setter and getter methods. These setters allow the presenter to make updates to the state of the view. The getters provide an abstraction over how the view stores the state and gives the presenter a way to get the information. The saveCastle function no longer passes any values to the presenter.
The presenter's code looks like the following:
class CreateCastlePresenter {
constructor(document) {
this.document = document;
this.model = new CreateCastleModel();
this.view = new CreateCastleView(document, this);
}
saveCastle() {
var data = {
name: this.view.getCastleName(),
description: this.view.getDescription(),
outerWallThickness: this.view.getOuterWallThickness(),
numberOfTowers: this.view.getNumberOfTowers(),
moat: this.view.getMoat()
};
var validationResult = this.validate(data);
if (validationResult.IsValid) {
//write to the model
this.saveCastleSuccess(data);
}
else {
this.view.setValid(validationResult);
}
}
saveCastleSuccess(data) {
//redirect to different presenter
}
validate(model) {
var validationResult = new validationResult();
if (!model.name || model.name === "") {
validationResult.IsValid = false;
validationResult.Errors.push("Name is required");
}
return;
}
}You can see that the view is now referenced in a persistent fashion in the presenter. The saveCastle method calls into the view to get its values. However, the presenter does make sure to use the public methods of the view instead of referencing the document directly. The saveCastle method updates the model. If there are validation errors, then it will call back into the view to update the IsValid flag. This is an example of the double dispatch I mentioned earlier.
Finally, the model remains unchanged from before. We've kept the validation logic in the presenter. At which level the validation is done, model or presenter, matters less than being consistent in where the validation is done through your application.
The MVP pattern is again a fairly useful pattern for building user interfaces. The larger separation between the view and the model creates a stricter API allowing for better adaptation to change. However, this comes at the expense of more code. With more code comes more opportunity for bugs.