Questo diagramma fornisce una buona rappresentazione del pattern MVVM?

0

Sto attraversando un momento difficile per capire la struttura di base del Modello, Visualizza, Visualizza modello del modello.

Sono stato onestamente piuttosto ignorante delle convenzioni sul modello di design fino a poco tempo fa. La mia educazione formale è nei media web, quindi sono entrato nella programmazione tramite Javascript. Ultimamente, però, sto costruendo da zero un complesso design di giochi come esercizio per sviluppare le mie capacità. L'interfaccia dovrà essere piuttosto estesa, con numerose uscite e controlli necessari. Questi controlli potrebbero dover influire sul modello, sulla vista o su entrambi.

Sono arrivato su MVVM dopo aver studiato MVC su suggerimento di un amico. MVC sembrava che sarebbe diventato piuttosto disordinato, con tutte le diverse visualizzazioni e controlli che avrò. All'inizio avevo l'impressione che MVVM fosse semplicemente un MVC con molti punti di vista in mente, ma ho avuto molto difficoltà a definire una definizione, o anche una struttura letterale.

Detto questo, ho creato il seguente diagramma nel tentativo di visualizzare i miei pensieri. Questo è pensato per rappresentare la struttura di base & propagazione dell'evento del pattern MVVM, come da quanto ho capito.

Perspiegarelamiacomprensioneaparole,direi:

Ilmodellocontieneidatielasimulazionestessisenzacontrolloovisibilità.Unmodellodivistatraduceleinformazionitrailmodelloelavistaedisponedipiùcontrolleralsuointernoperl'inputel'output.IlRaccoglitoreèinattesadiaggiornamentidelModelloodelModellodivisualizzazioneenotificaaipartneraccoppiatidellemodifichediciascunarticolo.Unavistaèsolounoutput"stupido" dato da un modello di vista e modificato dai suoi controllori.

A mio parere , vorrei confrontare i Modelli di vista con i dati di gioco. Ad esempio, il modello del gioco contiene tutti i dati come la posizione del giocatore, quindi un computer / loop di stato agisce e modifica questi dati. È simile alla relazione Visualizza modello / Visualizza controller? In che punto il modello di vista controllerebbe l'istanziazione e l'archiviazione dei dati (la vista), mentre i controllori gestiscono lo stato?

Questa è una rappresentazione accurata di MVVM e / o è un buon modello di progettazione per un game design?

O in altre parole, quali sono i modi in cui la mia rappresentazione differisce dal paradigma, che potrei volere / dover modificare?

A parte questo, utilizzo un "Controller" aggiuntivo per ingressi fisici / fuori schermo (come l'input da tastiera) o lo metto nel View Controller? (Con Javascript, il rilevamento dell'input da tastiera sarà comunque collegato alla superficie View (ad esempio canvas.addEventListener("keyup", func(ev)) )

Spero che il mio testo e le descrizioni grafiche non differiscano nelle loro implicazioni. Se lo fanno, fatemelo sapere.

Aggiornamento: Sto vedendo (ora) che sembra che la maggior parte delle implementazioni MVVM non "richiedano" il View Controller come lo ho qui. Io proprio non capisco, immagino. Ad ogni modo aggiornerò volentieri questo con uno schema fisso se qualcuno può aiutarmi a superare la mia vasta ignoranza. Penso che questo sia un ottimo modo per mostrare schemi di design, se solo sapessi cosa fosse in realtà!

    
posta Danie Clawson 29.09.2014 - 16:56
fonte

1 risposta

0

Stai mescolando MVC e MVVM qui un po '.

Semplicemente parlato:

  • In MVVM, crei una rappresentazione astratta della tua vista indipendente dalla tecnologia UI in uso e leghi la tua vista concreta (dipendente dalla tecnologia UI) ad essa con una sorta di codice collante.
  • MVC significa semplicemente: la vista ha un modello di strategia per comunicare con il modello ed è un osservatore del modello. Questo modello di strategia è chiamato "Controller"

The Model holds the actual data itself with no control or visibility.

Il modello non è solo dati. Il modello è la tua logica aziendale. Molte persone sbagliano. Non è solo una raccolta di attributi di dati incapsulati in classi, è anche un comportamento.

I am seeing (now) that it looks like most MVVM implementations don't "require" the View Controller as I have it here. I really just don't get it, I guess.

I tuoi nemici non sono così sbagliati. Vuoi mettere InputProcessors (li chiami controller) nel tuo ViewModel. Questo è imho ok per un gioco, ma se vuoi implementare il pattern il più puro possibile, devi associare i comandi da tastiera alle azioni che sono presenti nel tuo viewmodel. Quindi li legherei dalla vista concreta (keyevent) a viewmodel (azione).

    
risposta data 29.09.2014 - 17:33
fonte

Leggi altre domande sui tag