È comune / corretto utilizzare MVVM per aspettarsi più viste e corrispondenti modelli di visualizzazione per un particolare modello?

Question

È comune / corretto utilizzare MVVM per aspettarsi più viste e corrispondenti modelli di visualizzazione per un particolare modello?

#1 da (2 voti)

3

Considera un modello un po 'forzato che assomiglia a qualcosa di simile:

class Player
{
    public int Health;
    public int Ammo;
    public Weapon CurrentWeapon;
    public PhysicalState State
    {
        get
        {
            if (this.speed <= 0.1)
                return PhysicalSpeed.Standing;
            /* and so-on for Strafe_left, Running, etc. */
        }
    }
}

Nell'aspetto visivo atteso per un gioco del genere è noto che il display dell'HUD mostrerà cose come salute e munizioni, mentre l'avatar mostrerà l'arma e l'animazione in base allo stato fisico.

Quindi, supponendo che tu abbia una HUD_View e una Player_View che disegnano rispettivamente l'HUD e il player, è corretto, all'interno dei confini di MVVM, avere 2 view-models per il modello Player, che hanno sempre lo scopo di esporre un sottoinsieme di informazioni nel modello o si prevede che anche il modello verrà diviso in due?

C'è qualcosa che mi manca? Qualcuno può indicarmi o fornire un esempio più concreto della soluzione corretta (anche se il mio modo di pensare è corretto, in modo da poter solidificare la mia comprensione qui)?

design-patterns mvvm

posta Steven Evers 12.04.2011 - 04:28

fonte

1 risposta

Leggi altre domande sui tag design-patterns mvvm

Perché Wordpress e Drupal serializzano i dati del DB? Contratto per lo sviluppo di app e la manutenzione del servizio

score 2 · Accepted Answer

No, non credo che sia previsto un ViewModel per View.

Supponendo che HUDView & PlayerView rappresenta lo stesso oggetto concettuale - cioè lo stesso giocatore nello stesso contesto, che in questo caso fanno - quindi non ce n'è bisogno. Dovresti semplicemente replicare un sacco di codice e fare più lavoro per te.

Se hai bisogno di dividere in due ViewModels, allora fallo. Ma presumo che il tuo ViewModel sarà principalmente condiviso tra le due viste - ottenendo l'oggetto Player, aggiornando le proprietà su particolari eventi, se / allora funzioni. Dovresti creare solo una istanza di ViewModel in modo che le viste HUD e Player puntino entrambe agli stessi dati: aggiorni una singola proprietà, e entrambe le viste si aggiornano piacevolmente a turno.