MVC e le migliori pratiche di associazioni di cacao domanda

Question

Diciamo che ho una vista, myView, un controller di visualizzazione, myViewController e una sorta di oggetto modello, myModel. Inoltre, diciamo che il modello ha due proprietà conformi allo standard KVO, arrayOfPeopleNames e arrayOfAnimalKinds (entrambe NSStrings).

Dal mio punto di vista voglio avere due finestre pop-up legate al contenuto di questi due array.

La mia domanda è, se myController ha un riferimento a myModel, e il menu a discesa è associato a myViewController è buona norma impostare un keypath lungo le linee di myModel.arrayOfPeopleNames?

Oppure ho bisogno di impostare un NSArray aggiuntivo in myViewController che rispecchia quello in myModel e si collega invece a quel keypath?

Il primo sembra molto più semplice da un punto di vista dell'implementazione (non devo fare in modo che l'array del controller rispecchi l'array del modello), ma mi chiedo se esso espone il modello a molto più della vista.

Opinioni?

Answer 1

Non si deve eseguire il mirroring dell'array del modello nel controller. Anche se non mi preoccuperei troppo di legare direttamente all'array del modello in un caso molto semplice, potremmo anche legare gli oggetti dell'interfaccia utente a un NSArrayController, che gestisce l'array del modello. Ciò fornirebbe una separazione tra il modello e l'interfaccia utente e, soprattutto, gestirà attività come l'ordinamento, la selezione, l'aggiunta e la rimozione di oggetti e così via.

Posso vedere da dove vieni preoccupato KVO e binding viola il design del controller di visualizzazione modello "puro", ma non è qualcosa di cui dovresti preoccuparti. Anche se le notifiche KVO passano direttamente alla vista dal modello, l'impostazione e la modifica della connessione tra la vista e il modello è ancora responsabilità del controllore (solo in questo caso invece avviene tramite IB). Ad esempio, non si desidera che un oggetto del modello ottenga un riferimento alla vista e si leghi all'interfaccia utente, che sarebbe responsabilità del controllore.

Come altro esempio di qualcosa da evitare, considera se il tuo modello avesse una serie di "ID animali" invece di nomi. Invece di creare un metodo per tradurre gli ID degli animali in nomi animali leggibili nel modello, potresti invece voler creare un trasformatore di valori o un formattatore per eseguire la conversione. Ciò consente di mantenere quel livello di separazione tra il modello e la vista.

Ricordare inoltre che lo scopo dei modelli di progettazione è ridurre la complessità della codifica di una soluzione per un problema, non aumentarla mai. Vedrai che questo è esattamente il modo in cui funziona Cocoa, anche se potrebbe non sempre aderire alla definizione più rigorosa di un pattern.