Inizierò fornendoti grandi risorse per la progettazione MVC. La prima è la Sessione WWDC 2010 116 Model-View-Controller per iPhone OS (in realtà solo iOS), è leggermente adattata alle classi iOS, ma offre anche molte informazioni generalmente utili. Devi registrarti per diventare uno sviluppatore Apple (gratuito) per accedervi. Il secondo è il corso di Stanford iOS disponibile pubblicamente, anch'esso sarà adattato a iOS, ma la sua classe di introduzione si è concentrata su MVC in senso generale.
Ok, quindi quello che ottieni da quelle risorse sono regole come Viste che non possiedono i dati che visualizzano.
Direttamente dal corso di Stanford:
Model: What your application is (but not how it's displayed)
Controller: How your model is presented to the user (UI Logic)
View: Your controller's minions
Comunicazione
Controller: comunicazione diretta a modelli e viste.
Visualizzazioni: comunicazione "cieca" ai controllori (azioni-obiettivo e delega). Nessuna comunicazione ai modelli.
Modelli: trasmissione delle comunicazioni ai controllori (notifica e KVO). Nessuna comunicazione alle visualizzazioni.
Organizzazione
Per il tuo caso specifico, non sono sicuro di capire cosa stai descrivendo al 100%, non sono sicuro di quali siano questi "widget" (almeno per Android, un widget è un pacchetto di MVC che fornisce alcune funzionalità come un widget della barra di ricerca). Ma se vuoi dire che ListModel è qualcosa come un titolo e un indice implicito, e il DisplayModel è una descrizione corrispondente per l'indice dato, allora potrei avere un MainController (per la vista principale che contiene queste due sottoview o frammenti). L'utente seleziona una voce in ListView attivando una sorta di funzione onSelection sul MainController (ora il MainController sa quale elemento hanno selezionato). Il MainController lo passa accanto al DisplayController (ora il DisplayController sa quale oggetto hanno selezionato). Infine, DisplayController può utilizzare il DisplayModel per trovare ciò che deve essere visualizzato ora e quindi comunicare a DisplayView di visualizzarlo.
In alternativa, DisplayController può rispondere direttamente alla funzione onSelection attivata dalla selezione in ListController, ma collega componenti che probabilmente non dovrebbero essere collegati. Poiché hai detto che erano le loro Views che significa che sarebbe possibile avere un set up (possibilmente per schermi più piccoli) con ListView a schermo intero, viene fatta una selezione, quindi DisplayView riprende lo schermo mostrando la descrizione di la selezione fatta. Per questo motivo lascerei le viste separate.
Modifica
Quindi, iniziamo dicendo che MVC è solo una guida per produrre codice ben strutturato, per quanto ne so non è strettamente applicato. Successivamente, per il "non canonico" si riferisce a ciò che ciascun componente è supposto fare.
Essenzialmente, tutto ciò che non è scritto per mostrare qualcosa o interagire con lo schermo fa parte di un modello. I modelli sono gli algoritmi che eseguono i compiti. Le viste servono solo a far emergere un'interfaccia utente e forniscono modi per il programma di interagire con l'interfaccia utente (come nelle connessioni e nella delega dell'azione di destinazione). Ciò lascia i Controller a essere i delegati e gli obiettivi per le Visualizzazioni. Pensa al tipo di ingranaggi sotto le vedute che immagino. Dovrebbero essere il collegamento tra azioni sullo schermo e funzioni e dati nel modello. Dovrebbero assicurarsi che le visualizzazioni visualizzino il contenuto che si desidera visualizzare.
Ecco le foto tratte dal corso di Stanford (la prima classe) che mostrano come e come non impostare più MVC. (sfortunatamente posso pubblicare un massimo di 2 hyperlink e nessuna immagine)
MVC eseguito correttamente
MVC fatto in modo non corretto
