MVC Il modello può sapere NULLA della vista?

Se il modello non ha bisogno di conoscere la dimensione della vista (ad esempio per il rilevamento dei bordi o le collisioni), allora non penso che sia necessario avere queste informazioni. Il tuo modello può esprimere posizioni / distanze in un formato neutro ("unità di layout" o qualcosa del genere) che renderà più semplice la scalabilità per le varie dimensioni dello schermo? Oppure le dimensioni dello schermo influenzano il gameplay (potrebbero esserci più nemici / bersagli da tracciare su uno schermo più grande)? Se è così, allora ha senso definire la dimensione del campo di gioco nel modello.

Potresti provare a fare troppo nel modello. Se il modello deve preoccuparsi delle dimensioni dello schermo, direi che il design sta infrangendo alcune regole di MVC. Invece, perché il controller (o "relatore") non può conoscere le dimensioni dello schermo e adattare i dati del modello per farlo corrispondere? Il Controller è tecnicamente il posto giusto per qualsiasi logica che richieda la conoscenza sia della vista che del modello.

Non hai fornito molti dettagli specifici (ad esempio perché la dimensione dello schermo è importante); è giusto che tu voglia mantenere segreti sul tuo gioco, ma se puoi almeno dirci quale funzione di base viene eseguita che richiede dimensioni dello schermo, potremmo essere in grado di dirti meglio come implementare i pattern MVC nel tuo codice .

Non inserire alcun supporto per la presentazione nel modello. Ad esempio, un modello per una partita di scacchi tiene traccia delle posizioni del pezzo e del giocatore in movimento, segnala se il gioco è finito e produce un elenco di tutte le mosse legali. Tutte le logiche di presentazione, come il calcolo della posizione dello schermo per un quadrato sulla scacchiera e il rendering di un chessman, dovrebbero essere eseguite nella vista.

Se stai implementando più viste, calcola il codice comune in un modulo del servizio di visualizzazione o in una classe di base della vista.

È bene guardare il pattern MV * con più viste esistenti in parallelo sullo stesso modello (cioè come una corretta separazione tra dominio e presentazione dovrebbe funzionare, senza problemi). Da questo punto di vista, come potresti inserire le dimensioni dello schermo nel modello, quando potrebbero esserci più dimensioni dello schermo?

Cioè, MVP / MVVM fornisce una struttura leggermente migliore per risolvere questo problema: il presentatore (o il modello di visualizzazione) sono parti che conoscono le dimensioni dello schermo. Sono le parti responsabili della consegna dei dati da mostrare nella vista. Ma non il modello.

OTOH, c'è un'altra vista (specialmente quando si tratta di un gioco), dove la dimensione dello schermo dovrebbe essere parte di un modello - cioè quando il gioco logic dipende realmente da quella dimensione dello schermo.

Quindi, mi chiedo se le dimensioni dello schermo sono la parte necessaria della logica di gioco. In caso affermativo, fa parte del modello (e qualsiasi visualizzazione di tipo schermo è limitata solo a quella schermata). In caso contrario, è compito del presentatore / viewmodel occuparsi di questo (e molti altri, come skinning / temi per esempio) dei dettagli di presentazione.

Come al solito, la risposta dipende.

Se si utilizza un'astrazione per le dimensioni dello schermo nel modello, potrebbero vivere insieme. Ad esempio, il modello potrebbe conoscere la dimensione dell'universo o universo visibile . Questo sarebbe diverso a seconda del tipo di dispositivo o della dimensione dello schermo ... o semplicemente messo a seconda dell'hardware.

Se lo metti in questo modo, il tuo modello dipende dalle informazioni dell'hardware (livello più basso) e fa il suo lavoro. La vista prenderà qualsiasi cosa il modello gli dia e farà il lavoro di rendering sullo schermo.

D'altra parte, puoi anche usare un altro approccio. Potresti chiederti se il modello dovesse conoscere le coordinate? Non conosco la risposta a questo, dipende dalla tua applicazione. Forse potresti utilizzare visualizza gli helper per regolare le coordinate dove necessario.

Ricorda anche che molte volte l'ottimizzazione è il rovescio del refactoring o del rendere le cose giuste. Se si tratta di un colpo di performance con cui non si può convivere, sacrifica il design e fai in modo che il tuo programma faccia ciò che deve fare.