2015-05-12 8 views
6

Ich baue eine Android App mit MVP, und ich habe eine Frage zu diesem Muster.Model View Presenter - gleiche Ansicht, verschiedene Presenter

Sagen Sie, ich habe einen Bildschirm für Erstellen einer neuen Person. Dieser Bildschirm zeigt einen EditText zum Einfügen des Namens, einen anderen für den Nachnamen, einen ImageView, um das ausgewählte Foto anzuzeigen, usw. Dies wird zu einer View Schnittstelle führen, die von der Fragment implementiert wird. Es wird mit einer Presenter Schnittstelle zusammenarbeiten, die von einer anderen Klasse implementiert wird.

Fein.

Jetzt habe ich ein weiteres Feature: ein Bildschirm für Bearbeiten einer vorhandenen Person. Wie es passiert, ist die View für diese Funktion identisch mit der zum Erstellen einer neuen Person. Die Presenter ist jedoch anders. Es beginnt mit dem Laden der vorhandenen Person aus db, um die Ansicht mit den aktuellen Daten zu füllen, und die Aktion über die Datenbank beim Klicken auf "Speichern" ist ein Update anstelle einer Einfügung.

Also ich denke, das ist ein Beispiel für MVP , wo One View mit verschiedenen Implementierungen des Präsentators funktioniert, um verschiedene Anwendungsfälle zu erreichen.

  1. Glauben Sie, dass dies eine richtige Annahme ist, oder denken Sie, verschiedene Funktionen verschiedene View und Presenter Schnittstellen haben sollte?

  2. Auch

    , wenn Sie mit einer gemeinsamen View und verschiedenen Presenters werden, wird die Umsetzung der View gemeinsam sein, oder wäre es auf die gleiche Schnittstelle von zwei Klassen implementiert führen? In der Praxis sehe ich zwei Möglichkeiten.

    • Mit nur einem Fragment die View implementieren. Abhängig davon, ob der Benutzer eine neue Person erstellen oder eine vorhandene aktualisieren möchte, sollte das Fragment einen anderen Presenter erhalten und verwenden.

    • Mit zwei Fragment s. Jeder würde einen anderen Presenter instanziieren. Verwenden Sie Komposition oder Vererbung, um die Replikation von Code zwischen den beiden Fragmenten zu vermeiden.

Was denken Sie besser ist, in diesen Fällen zu tun?

Danke.

+0

Ich denke, Sie sind auf dem richtigen Weg. –

+0

Sie können die gleiche 'Ansicht' teilen und haben nur ein' Fragment', das je nach Verwendungszweck einen anderen 'Moderator' erhält (bearbeiten oder erstellen). – pdegand59

Antwort

0

Sie werden darauf stoßen, wenn Sie eine CRUD-ähnliche Anwendung mit dem MVP-Muster auf Android erstellen.

Sie können ganz einfach nur noch die einzige Ansicht, so lange wie Sie auch in Ihrer Klasse zu dokumentieren, dass sie die ‚Aussicht‘ für zwei verschiedene Moderatoren impl, dann ist es in Ordnung "


würde ich Ich schlage persönlich vor, 2 Ansichten zu erstellen, eine für "create" und eine für "edit" (Sie könnten die gleichen sein (vorerst), aber wenn sie voneinander getrennt werden, wird deutlich, dass es sich um verschiedene Dinge handelt.)

Sie könnten leicht eine Situation in der Zukunft (oder eine andere Impl dieses Musters) sehen, wo Ihre Ansichten 'Erstellen' und 'Bearbeiten' tatsächlich unterschiedliche APIs haben. Oder etwas andere visuelle Hinweise, wie zum Beispiel eine Schaltfläche mit dem Namen "Erstellen/Hinzufügen" in einem und "Aktualisieren" in einem anderen.

Ich würde persönlich eine View-Bibliothek/Helfer-Klasse, die beide Ansichten Logik ziehen. Dies sollte Ihnen helfen, den Gesamt-LoC zu reduzieren, selbst wenn Sie 2 "View" -Klassen erstellen. Dies hat den Vorteil, dass Sie entweder die Ansichten "Erstellen/Bearbeiten" einfach ändern können, ohne dass Sie sich Sorgen darüber machen müssen, ob die anderen Auswirkungen haben. (Ich tendiere dazu, die 2 View-Dateien zu denken, wäre leichter zu pflegen, wenn es sogar eine 'leichte' Abweichung zwischen Create/Edit gibt).