In MVC dove metti riferimenti al tuo modello Classi?

Question

Mi sono chiesto per un po ', dopo aver chiesto diverse persone e senza di loro fornendo quello che chiamerei un "almeno un po' risposta concreta":

Domanda:

Dove, in un L'applicazione iPhone dovrebbe un'applicazione mantenere i riferimenti alle sue Classi di modelli (usando l'approccio MVC)?

Nelle applicazioni iPhone (e Cocoa) abbiamo quello che chiamiamo il "Delegato app", che sostanzialmente avvia la nostra applicazione e nei nostri controllori, gestisce anche gli eventi UITouch.

Quindi l'App delega un controller? una classe modello? nessuno dei due? Penso che non sapendo che rende anche confuso sapere dove mettere i riferimenti del modello.

Esempio:

Avete il delegato applicazione, che delega contiene un riferimento a View Controller dell'applicazione. Se la mia applicazione utilizza la classe di modello A (che è una classe daemon webserver) e una classe B che memorizza i dati interrogati da quel server web.

Dove vorresti memorizzare i riferimenti A e B? (App Delegate? Vedi Controller? Entrambi?)

Ci sono molte opzioni qui, ma ad esempio, mi piacerebbe davvero sapere come vorresti usare mvc per mettere insieme questa applicazione che utilizza solo una vista.

Answer 1

Si è tentati di mettere tutto in AppDelegate, ma se si inizia a farlo, il tuo AppDelegate sarà pieno di hack di riferimento. Se stai facendo un rigoroso MVC, allora si dovrebbe avere 3 cose:

• un modello
• A View Controller (solo per la logica di vista)
• un controller (per il coordinamento tra la vista e il modello)

Quindi, ad esempio, ho un modello Foo e un controller Foo. Avrei:

• Foo.m (Model)
• FooViewController.m (Visualizza un Foo)
• FooController.m (controlla la logica)

E, infine, per rispondere alla tua domanda, memorizzerei i miei riferimenti a Foo's in the foo Controller. Mi piace usare i singleton per i miei controller, ma sono solo io. Se si utilizza un singleton, si può solo fare qualcosa di simile: [[FooController sharedInstance] listOfFoos] per ottenere il vostro Foo

Answer 2

Tradizionalmente il controllore crea il modello e poi inizializza la vista con quel modello. Il controller quindi ascolta i cambiamenti nel modello e visualizza e coordina il flusso del programma attraverso questo. Questa sarebbe la mia risposta generica, forse le cose nella pratica sarebbero diverse per lo sviluppo di iPhone.

Answer 3

Dove, in un'applicazione iPhone, un'applicazione deve mantenere i riferimenti alle classi di modelli (utilizzando l'approccio MVC)?

Il livello controller mantiene i riferimenti al livello del modello.

Quindi l'App delega un controller? una classe modello? nessuno dei due?

Il delegato dell'app è un controller.

Dove vorresti memorizzare i riferimenti A e B?

A e B sono classi di modelli che di solito vengono creati e di proprietà del livello controller.

Mi piacerebbe davvero sapere come vorresti usare mvc per mettere insieme questa applicazione che utilizza solo una vista.

Lo scopo del livello controller è consentire al modello e ai livelli di visualizzazione di essere autonomi. Il modello non dovrebbe sapere nulla sul controller o sui livelli di visualizzazione. La vista non dovrebbe sapere nulla sul controller o sui livelli del modello. Il compito del controllore è di essere un adattatore a doppia estremità per il modello su un lato e la vista sull'altro.

vorrei impostare il vostro esempio app come questo:

• delegati UIApplication a AppDelegate.
• Se il funzionamento della classe di server (A) è semplice:
  • AppDelegate crea e possiede esempio (s) di classe del server A.
• Se il funzionamento della classe di server (A) è complicato:
  • Creare una classe controller dedicata (C) per controllare il server.
  • AppDelegate crea e possiede istanza (s) di classe C. Un'istanza di (C) per ogni istanza di (A).
  • Ogni istanza di classe C crea e possiede un'istanza di classe A.
• AppDelegate crea e possiede un'istanza della classe ViewController, che carichi e possiede la vista.

Non è chiaro nella domanda qual è lo scopo della classe B.

• Se si tratta di una porzione di dati utilizzabile solo da A (come dati di configurazione o dati di siti Web statici), è necessario che sia creata e di proprietà del server (A).
• Se si tratta di dati che si crea durante il funzionamento del server e deve essere visualizzato nella vista, quindi probabilmente si desidera qualcosa di simile:
  • Una serie mutevole di proprietà di A, per contenere le istanze di B.
  • Un'altra classe controller (D) per fare riferimento a tale array e agire come origine dati/delegare alla vista.

Answer 4

Nelle mie applicazioni di solito rinominare la classe AppDelegate a AppController, se questo aiuta a spiegare meglio le cose concettualmente. Il controller dell'app è responsabile della creazione e/o della configurazione del controller modello (che gestisce la raccolta di oggetti del modello) e della finestra o dei controller di visualizzazione, dell'impostazione dei riferimenti tra di essi, se necessario, e dei metodi di chiamata su tali controller in risposta ai metodi delegati NSApplication o metodi di azione di alto livello dal menu principale. A seconda della complessità della tua applicazione, potresti avere anche controller modello o vista aggiuntivi creati al di fuori del tuo controller dell'app.

Ovviamente, se si dispone di un'applicazione semplice, non vi è alcun motivo per cui il controller dell'app non abbia il ruolo del controller del modello, se lo si desidera. Quello che vuoi evitare è archiviare centinaia di righe di codice, tutte attività concettuali non correlate.

Answer 5

Trovo che nella maggior parte dei casi AppDelegate offra una buona posizione per posizionare alcune funzionalità di base (come un'immagine di sfondo che si desidera applicare in ogni controller), ma che vorrà avere controller e codice modello aggiuntivi altrove. Un controller di navigazione o rootController viene spesso inserito come proprietà su AppDelegate.

Quindi, direi che è da qualche parte tra "nessuno" e "controller", ma si appoggia più verso "nessuno". Sicuramente non "modello"!