{"id":1282,"date":"2012-04-01T15:04:18","date_gmt":"2012-04-01T13:04:18","guid":{"rendered":"http:\/\/www.tutego.de\/blog\/javainsel\/?p=1282"},"modified":"2020-06-21T18:18:47","modified_gmt":"2020-06-21T16:18:47","slug":"mvp-model-view-presenter-mit-gwt-teil-1-einfhrung-in-die-konzepte","status":"publish","type":"post","link":"https:\/\/www.tutego.de\/blog\/javainsel\/2012\/04\/mvp-model-view-presenter-mit-gwt-teil-1-einfhrung-in-die-konzepte\/","title":{"rendered":"MVP (Model-View-Presenter) mit GWT"},"content":{"rendered":"

Zum Thema MVP (Model-View-Presenter) gibt es schon einiges an Dokumentation, etwa https:\/\/developers.google.com\/web-toolkit\/doc\/latest\/DevGuideMvpActivitiesAndPlaces,<\/a> https:\/\/developers.google.com\/web-toolkit\/articles\/mvp-architecture<\/a>, doch soll dieser Beitrag einen weiteren Zugang zu dem Thema schaffen.<\/p>\n

In einer MVP Anwendung macht die Sicht nur das, was sie machen soll: sie zeigt an. Sie ist zudem immer technologieabh\u00e4ngig und es kann verschiedene Implementierungen geben, etwa f\u00fcr GWT, Swing oder als Mock f\u00fcr Tests. Der Presenter ist mit der View assoziiert, aber da die View ja immer anders aussehen kann, kennt der Presenter sie nur \u00fcber eine Schnittstelle. Damit beginnen wir (alle Programme im Pseudeocode):<\/p>\n

interface MyView extends IsWidget {\n  void setName( String name );\n  String getName();\n}<\/pre>\n
In der Schnittstelle kommen bis auf IsWidet keine GWT-spezifischen Eigenschaften nach au\u00dfen, wobei es Entwickler gibt, die hier GWT-Schnittstellen wie HasText, IsWidget oder HasClickHandlers verwenden, dazu gleich mehr. Auch werden keine View-Model-Objekte (etwa Person) verwendet, sondern einfache Datentypen.<\/p>\n
Die Implementierung f\u00fcr GWT kann den UiBinder nutzen oder nicht. Ohne sieht es etwa so aus:<\/p>\n
class MyViewImpl extends Composite implements View {\n\n  private TextBox textbox;\n\n  MyViewImpl() {\n    initWidget( textbox );\n  }\n\n  @Override public void setName( String name ) { textbox.setValue( name ); }<\/strong>\n  @Override public String getName() { return textbox.getValue(); }<\/strong>\n}<\/pre>\n
So einfach ist die View (die wir sp\u00e4ter noch ausbauen).<\/p>\n
Nun kommt der Presenter, der die View initialisiert und auch die Interaktion mit dem Backend \u00fcbernimmt. Wie stark er mit der View interagiert ist Geschmacksache.<\/p>\n
Da der Presenter die View initialisiert und auf die View Einfluss nimmt, muss folglich der Presenter ein Verweis auf die View bekommen. Der Presenter merkt sich die View in einem Attribut:<\/p>\n
class MyPresenter\n{\n  private MyView myView;\n  \u2026\n}<\/pre>\n
Es gibt unterschiedliche Wege, wie der Presenter zur View kommt. Wenn man die View nicht<\/em> austauschen m\u00f6chte (und auch sonst einige Nachteile in Kauf nicht, siehe sp\u00e4ter), kann man den Presenter selbst die View erzeugen lassen. Oder man bietet einen Setter oder man l\u00e4sst den Presenter injizieren. Die letzten beiden Wege erlauben den einfachen Austausch der View, etwa im Testfall. Au\u00dferdem muss die View nat\u00fcrlich an h\u00f6her liegender Stelle irgendwie verf\u00fcgbar sein, wenn zum Beispiel die MyView auf den Root-Panel gesetzt wird. Wenn man die View injiziert oder sie dem Presenter \u00fcber einen Setter setzt, gibt es eine zentrale Stelle (ClientFactory in der GWT-Doku genannt) und von dort kann man diesen Teil-View f\u00fcr die jeweils dar\u00fcber liegende View erfragen. Oder man fragt den Presenter selbst, wenn man sich so eine zentrale Stelle sparen m\u00f6chte. In meinem Beispiel deklariere ich eine Methode getView() und mein Presenter erzeugt die View auch selbst:<\/p>\n
class MyPresenter\n{\n  private MyView<\/strong> myView = new MyViewImpl();\n\n  MyView<\/strong> getView() { return myView; }\n}<\/pre>\n
Wenn man die View nun auf das Root-Panel setzen m\u00f6chte, sieht das so aus:<\/p>\n
MyPresenter presenter = new MyPresenter(); \nRootLayoutPanel.get().add( new ScrollPanel( presenter.getView() ) );<\/pre>\n
Einschub: Die Methode getView() kann man nat\u00fcrlich \u00fcber eine neue Schnittstelle Presenter vorschreiben lassen, die etwa so aussehen kann:<\/p>\n
public interface Presenter<T extends View> { \n  T getView(); \n}<\/pre>\n
In eigenen Projekten hatte ich das urspr\u00fcnglich so entworfen, darin aber keinen Nutzen gefunden, und diese allgemeine Presenter-Schnittstelle wieder verworfen. Zudem h\u00e4tte das auch eine View-Schnittstelle n\u00f6tig gemacht, doch diese Abstraktion brachte mir nichts.<\/p>\n
Erzeugt der Presenter die View muss man sich nat\u00fcrlich der Konsequenzen bewusst werden. Damit kann die View nicht mehr so einfach ausgetauscht werden (nur, wenn sie \u00fcber eine Fabrik kommt), und es bringt auch den Nachteil mit, dass eine neuer Presenter-Instanz immer eine View neu erzeugt. Die View ist dann kein Singleton, die resettet und in nachfolgenden Presenter-Instanzen wiederverwendet wird. So wird jede neue Presenter-Instanz eine neue View-Instanz bilden. In meinem Beispiel soll das Ok sein, doch sollte man sich bei performanten GWT-Anwendungen im Klaren sein, die View nicht immer wieder neu zu erzeugen. Um eine zentrale ClientFactory kommt man nicht drum herum.<\/p>\n
Im Grunde haben wir mit den drei Typen schon ein MVP realisiert:<\/p>\n