Nel pattern MVP, Presenter deve controllare il flusso di chiamate dei metodi Model?

Il metodo potrebbe essere parte del presentatore, potrebbe rimanere nel modello o potrebbe essere spostato in una classe helper o controller separata. Nessuno di questi posizionamenti è sempre "migliore" o "migliore pratica". Quale scegliere dipende da fattori come la complessità di tale operazione, ha senso solo in combinazione con quelle operazioni di visualizzazione / presentazione, vuoi che sia unitamente testabile, o come organizzi le responsabilità tra i livelli del tuo programma? Ad esempio, il metodo potrebbe assomigliare a questo:

 void createRoom(RoomData roomData, List<User> users) 
 {
     sendEventBeforeCreateRoom();
     addUsersToRoom(roomData.getId(),users);
     sendEventUsersAdded();
     joinRoom(roomData.getId());
     sendEventRoomCreated();
 }

Il problema qui è quello che quei metodi "sendEvent" sono:

• Se il metodo è nel modello, è necessario che siano metodi di attivazione evento e quindi è necessario un meccanismo evento nel livello del modello.

• Se non vuoi il secondo, o se il metodo in realtà è così complesso che giustifica una classe a sé stante, puoi metterlo in un controller separato e classi come il presentatore devono iscriversi a quegli eventi primo. Questo rende il codice più complesso, ma il vantaggio è che ora puoi testarlo più facilmente in isolamento.

• Se si posiziona il metodo nel presentatore, i metodi "sendEvent" potrebbero essere sostituiti da chiamate dirette ai metodi corrispondenti del presentatore. Questo è l'approccio più semplice, ma offre meno flessibilità per testare o riutilizzare il metodo in un contesto diverso

Quindi scegli la tua scelta su quale tipo di flessibilità hai bisogno (ma non aggiungere alcuna flessibilità "nel caso in cui"). Se risulta che non hai davvero bisogno di quei metodi di sendEvent , mantenere il metodo nel modello sarebbe stata probabilmente la scelta più semplice e quindi migliore.

Lasciare createRoom nel modello. Lancia MVP fuori dalla finestra per un minuto e guarda questo elenco: {createRoom, displayRoomToUser, addUsersToRoom, joinRoom}.

Quale metodo non è come gli altri? Ovviamente displayRoomToUser non appartiene. Tuttavia, gli altri 3 "sembrano" come se fossero tutti insieme. Se stavi facendo una lezione, sembra logico che questi 3 metodi appartengano tutti alla stessa classe.

Cerca di trovare un modo per abilitare la funzionalità che cerchi mentre segui lo spirito del paradigma, piuttosto che forzare il paradigma ad adattarlo al tuo stile di codifica. Spesso ci sono soluzioni eleganti.

Informazioni sulla tua domanda:

Nel Pattern MVP il relatore è responsabile per l'associazione della vista e del modello. È responsabile per far fronte alle interazioni emesse dalla vista e per selezionare i dati dal modello e per emettere comandi alla modella

In questa prospettiva, la tua domanda potrebbe essere riformulata:

• " creaRoom rappresenta un'interazione che combina solo addUsersToRoom e JoinRoom? " - Quindi è perfettamente valido spostarlo nel presentatore.
• " Oppure cambia anche qualcos'altro nel modello? " - Dovrebbe quindi rimanere nel modello e sarebbe una cattiva pratica spostarlo nel presentatore.

Informazioni sul tuo vero bisogno

Indipendentemente dalla risposta, la tua preoccupazione sembra essere il metodo call of view per riflettere i cambiamenti di base del modello (come joinRoom e AddUsersToRoom). Questo non è direttamente correlato a createRoom, poiché le altre modifiche potrebbero essere attivate direttamente comunque.

È necessario organizzare una notifica della vista per gli eventi delle modifiche rilevanti nel modello. La vista dovrebbe essere abbonata a queste notifiche di eventi (ad esempio il pattern di osservatore) tramite il Presenter. La notifica può essere implementata tramite relatore o direttamente dal modello, in base alla variazione del pattern MVP che si utilizza.