Quanti presentatori dovrei usare nell'appropriato MVP?

Question

Quanti presentatori dovrei usare nell'appropriato MVP?

#1 da (4 voti)

4

Ho un'app per Android che eseguo il refactoring per utilizzare MVP. Ho un'attività con due frammenti.

Scenario 1 (un presentatore): Il presentatore "conosce" ogni vista. Quindi, se una vista riceve input viene chiamato un metodo presenter e può chiamare un metodo di una qualsiasi delle viste.

Vantaggio: flessibile
Svantaggio: il presentatore potrebbe diventare veramente grande

Scenario2(trerelatori):Ognipresentatoreconoscesololapropriavisioneequalsiasialtropresentatore.Chiamaimetodisolosuglialtripresentatoricheconosceosullapropriavista.

Vantaggio:rigidamodularità,ilflussopuòesserepiùovvio
Svantaggio:unsaccodioverhead(altredueinterfacceeclassirelatore).

Questo è inteso per una sola attività e non per la comunicazione tra le attività.

Qual è il modo di andare con MVP o dipende dal caso d'uso?

Modifica: tendo a utilizzare la struttura descritta nel primo scenario. Ha più senso per me. Il mio unico problema è che non so se questo è MVP corretto o sto inventando qualcosa di nuovo da solo (che non voglio).

architecture design-patterns mvp android

posta Willi Mentzel 29.05.2017 - 23:16

fonte

1 risposta

Leggi altre domande sui tag architecture design-patterns mvp android

Abuso di commenti XML per mantenere aggiornati i commenti (in C #) Una classe immutabile può avere un costruttore di argomenti zero?

score 4 · Accepted Answer

Rendere i presentatori dipendenti l'uno dall'altro non sembra giusto. Le dipendenze sono tali che avrai bisogno di tutte le visualizzazioni e di tutti i relatori per far funzionare una coppia di View e Presenter.

Penso che sarà meglio rendere i Presentatori indipendenti l'uno dall'altro. Puoi mettere tutte le funzionalità comuni in un altro livello che può essere utilizzato da tutti i Presentatori.

Dalla mia comprensione superficiale del modello MVP nelle app Android, una semplice app è costituita dai seguenti componenti.

Sedisponidiun'Appcompostadapiùviste,conciascunavistaconunpresentatorecorrispondente,suggeriscolaseguentearchitettura.

PresenterCommon è pensato per essere indipendente dai singoli Presentatori. Può comunicare con i Presentatori usando un'interfaccia astratta che è nota ma non dovrebbe conoscere alcuna cosa specifica su un particolare Presenter N. Presenter N, d'altra parte, è inteso a essere a conoscenza di PresenterCommon e può effettuare chiamate dirette ad esso. Il presentatore N deve essere registrato con PresenterCommon a un certo punto.

Qualsiasi modifica apportata al modello da una qualsiasi delle viste viene comunicata agli altri visualizzatori da PresenterCommon utilizzando un'interfaccia di Presenter astratta.