Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Does Presenter in Model-View-Presenter create views?

How are Views created in MVP? Does the Presenter always create them (in addition to View in case of subviews)? Or is it a separate third-party component or App or something that creates them?

Let's also add that I'm probably going to do this on Dojo Toolkit/ExtJS (JavaScript that is).

So, I have these code lines:

var v = new MyApp.view.User(); var p = new MyApp.presenter.User(); 

where should both lines go exactly? Does the presenter instantiate the view, or vice-versa? And what instantiates the first instance?

like image 627
Tower Avatar asked Jun 06 '11 07:06

Tower


People also ask

How does Model View Presenter work?

Data (model) and UI (view), only communicate with one another through an intermediary (the presenter) . The presenter contains the bulk of the business logic, while the view focuses on how to display the data. The controller responsibility is now split between the view and presenter.

How does Android MVP work?

What is MVP? The MVP pattern allows separating the presentation layer from the logic so that everything about how the UI works is agnostic from how we represent it on screen. Ideally, the MVP pattern would achieve that the same logic might have completely different and interchangeable views.

What is presenter in MVP Android?

Model–view–presenter (MVP) is a derivation of the model–view–controller (MVC) architectural pattern which mostly used for building user interfaces. In MVP, the presenter assumes the functionality of the “middle-man”. In MVP, all presentation logic is pushed to the presenter.

What is contract in MVP?

Key Points of MVP ArchitectureCommunication between View-Presenter and Presenter-Model happens via an interface(also called Contract). One Presenter class manages one View at a time i.e., there is a one-to-one relationship between Presenter and View.


1 Answers

It depends ...

The main goal of MVP is to separate complex decision logic from UI code in such a way that both become easier to understand and to maintain. Often another goal is to make the decision logic in the presenter testable.

The MVP pattern was described by Fowler in 2004 and he retired it in 2006 by splitting the pattern into Supervising Conroller (SC) and Passive View (PV). In SC, the View is bound to the Model but not in PV; in PV, the View is only changed by the Presenter directly.

In both SC and PV, the Presenter has to update the View and react to changes the user made to the View, such as entering text or pressing a button. When you let the View call methods on the Presenter, then the problem you describe arises because the View needs a reference to the Presenter and vice versa. If you do this, you simply can make a decision who starts it all up. Options are:

  1. The View creates an instance of the Presenter. When the View is loaded, it passes itself to the Presenter in an initialize function on the Presenter.
  2. The other way around: Presenter creates View and passes itself to the View in an initialize function on the View.
  3. You introduce a third object that creates both View and Presenter, wires them together and initializes them both.

All options allow you to reach "MVP goals" of separation of concerns and increased testability of decision logic. I don't think any of these methods is theoretically right or wrong –you just have to pick the one that is most appropriate to the technology you use. And it's best to be consistent in your choice throughout the application.

like image 116
Marijn Avatar answered Sep 23 '22 08:09

Marijn