Come usare esattamente il modello di progettazione MVC

Question

Come usare esattamente il modello di progettazione MVC

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

6

Ho letto la documentazione sul sito web degli sviluppatori di Apple che si riferisce alle seguenti linee guida

A view class shouldn't depend on a model class (although this may be unavoidable with some custom views).

A view class shouldn't have to depend on a mediating controller class.

A model class shouldn't depend on anything other than other model classes.

A mediating controller class shouldn’t depend on a model class (although, like views, this may be necessary if it's a custom controller class).

A mediating controller class shouldn't depend on view classes or on coordinating controller classes.

A coordinating controller class depends on classes of all MVC role types.

Considera questo scenario:

Ho una classe di controller di visualizzazione chiamata EmployeeViewController . Ho alcuni componenti minori di cui alcuni sono creati a livello di codice e alcuni sono creati tramite xib .

Quello che sto facendo è creare tutte le visualizzazioni secondarie all'interno della classe EmployeeViewController e aggiungerle alla vista di EmployeeViewController , ad es. [self.view addSubView:…]

È un'opzione migliore per me creare una sottoclasse UIView separata che consiste di tutti i componenti e inizializzarla una volta e aggiungerla in EmployeeViewController ?

Qual è esattamente il modo corretto di implementare MVC? Dovrei creare componenti separati per la visualizzazione e il controller o devo impilare le visualizzazioni secondarie all'interno di EmployeeViewController ?

object-oriented ios mvc

posta BoredToDeath 09.05.2014 - 13:34

fonte

3 risposte

Leggi altre domande sui tag object-oriented ios mvc

Aiuto / suggerimenti per la pianificazione parallela della catena di montaggio (programmazione dinamica) Quando, se mai, dovrei usare le funzioni a catena?

score 1 · Answer 1

Il concetto base di MVC è quello di disaccoppiare i componenti (cioè il modello, la vista e il controller).

I vantaggi di questo approccio sono: meno dipendenze tra i componenti; più flessibilità; e quando il design della tua applicazione cambia, devi solo cambiare il codice in una posizione, non più.

Ad esempio, in Struts, tutta la configurazione sarà scritta in struts.xml e la mappatura sarà fatta in modo tale che per ogni azione ci sarà un risultato (definito JSP).

Se vuoi modificare il design o il flusso, devi solo modificare struts.xml .

score 0 · Answer 2

La domanda che fai non è tanto su come utilizzare MVC in generale, ma su come gestire / implementare le viste composite specifiche di cui hai bisogno.

Quindi, avendo le basi e lo scopo del modello di progettazione MVC, la risposta potrebbe richiedere più percorsi:

A. utilizzare un modello di iniezione di dipendenza nella vista principale, ad es. Vista di EmployeeViewController per aggiungere / iniettare qualsiasi sotto-vista di cui potrebbe aver bisogno

B. a seconda della vista / classe responsabile del dato / modello, la vista principale stessa può generare le sotto-viste e inizializzarle

C. non utilizzare le viste secondarie, ma ricostruire la vista principale per gestire i dati da sola in una vista

score 0 · Answer 3

Quindi per me MVC riguarda interamente la struttura del progetto, ed ecco come scompongo MVC.

M per Model: questo è tutto ciò che ha a che fare con i dati. Dai tuoi dati principali, alle tue chiamate di rete, agli oggetti che riformattano o traducono i dati per prepararli all'app. Fondamentalmente dove va tutta la logica cool.

V per View: quest'area se per cose che interagiscono direttamente con l'utente come storyboard e xibs. Questo è praticamente tutto.

C per controller: questo codice è un codice che accetta i dati dal livello Model (con i dati prontamente formattati) e quindi lo trasforma in qualcosa che può essere presentato nel livello View. Fondamentalmente si tratta di tutti i ViewController.

La cosa fondamentale di questo approccio è che il tuo livello Model dovrebbe essere in grado di essere estratto e applicato, ad esempio, a un'app Mac con modifiche minime, dove come V & C dovrebbe essere esplicitamente pertinente per iOS.

Questo è il modo in cui mi è stato insegnato MVC, ma sono sicuro che ci sono più interpretazioni.

Ora per l'implementazione, è difficile dare consigli esatti senza codice di esempio ma, in generale, sembra che la maggior parte delle cose di View sia programmatica che dovresti evitare se puoi. Approfitta degli storyboard e dei xib per occuparti del contenuto statico.

Per quanto riguarda le UIViews, questa non è una domanda MVC in quanto è una domanda di progettazione software. Tutto dipende dalla complessità di quella vista. Se è una sottoview estremamente complessa e dettagliata, allora sì lo tiri fuori nella sua classe. Ma se si tratta solo di un UIView di base con poche etichette, è sufficiente crearlo nel ViewController. Cerca di aderire alla filosofia Unix secondo cui ogni classe dovrebbe fare solo una cosa e farlo estremamente bene . Non preoccuparti se la tua classe ha solo una funzione al suo interno. Se si tratta di una funzione importante e unica, in realtà sarebbe preferibile averla disgiunta dal livello Controller e nel livello Modello. Vedo troppe persone che hanno paura di suddividere il loro codice in classi semplici, ma questo è in realtà il modo migliore per andare, avere tutto disaccoppiato e quindi facilmente plug-n-play.

Quindi, in conclusione, è la tua chiamata. Quanto è complesso questo UIView? Se richiede un paio di funzioni di supporto e variabili globali, estraila in una sottoview.