Lavoriamo in un negozio Java qui e la nostra applicazione web utilizza un'implementazione del MVP modello architettonico. Il nostro manager proviene da un mondo .NET, dove è stato esposto al modello di design MVVM . Il nostro manager sta sostenendo i cambiamenti nella nostra implementazione MVP, compreso il fatto che i Presentatori dovrebbero essere disaccoppiati (o liberamente accoppiati, a seconda della tua interpretazione) delle sue Viste attraverso il modello di progettazione di Observer, nella tradizione con MVVM. Sono più dell'opinione che il Presentatore e la Vista lavorino insieme per raggiungere un obiettivo comune, e come tale dovrebbero essere accoppiati.
Tra gli argomenti sollevati a sostegno del cambiamento c'è la possibilità di testare i presentatori. Se i relatori vedono solo le visualizzazioni come osservatori, l'argomento va, quindi possono essere più facilmente testati. Ma i relatori strongmente accoppiati alle loro opinioni non sono necessariamente difficili da testare. Se la vista utilizza il paradigma Visualizzazione umile , può essere deriso. Infine, la testabilità dovrebbe essere un sintomo di buona progettazione, non un driver per la progettazione.
Un altro argomento utilizzato dal mio manager per supportare la sovrapposizione di Views e Presenters è la supposta maturità di MVVM. Pertanto, dovremmo seguire gli insegnamenti di MVVM e adattarci alla sua implementazione di MVP. Correggimi se sbaglio, ma MVVM impone la stratificazione (artificiale) di visualizzazioni e presentatori per facilitare i suoi binding di dati nei controlli.
Puoi aiutarci a vedere la luce qui? Perché dovremmo usare un modello disaccoppiato e pagarne il prezzo? Non vedo il beneficio. Il rasoio di Occam dice che ho bisogno di argomenti per usare il disaccoppiamento, e il test non sembra essere uno di questi.
Chiarimento : quello che cerco davvero con questa domanda sono gli argomenti che possono far pendere l'equilibrio in favore di un presentatore che non conosce la sua vista e spara eventi nell'etere o a favore di un presentatore che conosce la sua vista (s) attraverso un accoppiamento più diretto, come un'interfaccia vista umile o direttamente alla classe. Nota che i presentatori possono facilmente servire più visualizzazioni con accoppiamento libero e stretto. La differenza sta nell'interfaccia a cui il presentatore parla: con un accoppiamento lento, il relatore parla con le classi dell'ascoltatore (o con un rappresentante del bus eventi), mentre con accoppiamento stretto, il presentatore parla all'interfaccia vista.