Ci sono molte viste differenti su come dovrebbero essere esattamente i pattern "MVC", ma sosterrò che non c'è nulla di intrinsecamente sbagliato con i controlli che attivano il comportamento sulla loro vista genitore. Tuttavia, ciò che è responsabile della funzione // do something
è importante.
Le azioni e le uscite sono strumenti per gestire la configurazione di una classe distribuita tra i file sorgente e .xib
. L'uso di quelli da solo ti dice molto poco su quale interfaccia hai progettato per un componente specifico e su quanto siano appropriate le responsabilità di quel componente.
La mia regola qui è che una classe vista dovrebbe accettare uno stato immutabile per visualizzare ed emettere messaggi sull'intento dell'utente, ma non essere consapevole o preoccupata di come l'applicazione risponde a tale intento. Ad esempio, una vista potrebbe segnalare che un utente desidera selezionare o eliminare un elemento da un elenco o incrementare un valore o inviare un modulo. Se quei desideri possono essere rispettati e il modo in cui vengono eseguiti non è il lavoro della vista. Inversamente la vista non dovrebbe contenere dettagli di implementazione su come ha determinato l'intenzione dell'utente. Nessun altro componente deve sapere quali pulsanti esistono all'interno della vista o dove si sono verificati i tocchi. Fatto bene, questo significa che potrei completamente sostituire l'implementazione della vista con una nuova serie di controlli senza modificare alcuna altra parte dell'app.
È quindi assolutamente ragionevole avere una vista con IBActions interne per mantenere privati i dettagli della struttura della sottodirectory della vista ed esporre un'interfaccia appropriata al resto dell'app.