I am having a really hard time understanding the basic structure of the Model, View, View Model pattern.
I have honestly been pretty ignorant of design pattern conventions until recently. My formal education is in web media, so I got into programming through Javascript. Lately, though, I've been building a complex game design from scratch as an exercise to build my skills. It's interface will need to be rather extensive, with numerous outputs and controls required. These controls may need to affect the Model, the View, or both.
I arrived at MVVM after researching MVC at the suggestion of a friend. MVC looked like it would get rather messy, with all the different views and controls I'll have. At first I was under the impression that MVVM was simply an MVC with many views in mind but I have had a very hard time nailing down a definition, or even a literal structure.
That being said, I have created the following diagram in an effort to visualize my thoughts. This is meant to represent the basic structure & event propagation of the MVVM pattern, as per my understanding of it.
To explain my understanding in words, I would say:
The Model holds the actual data and simulation itself with no control or visibility. A View Model translates information between the Model and View, and has multiple Controllers within it for input and output. The Binder listens for updates to either the Model or the View Model and notifies each item's paired partner(s) of changes. A View is just a "dumb" output given by a View Model and modified by its Controllers.
As my understanding goes, I'd like to compare View Models to the game data. For example, the game Model holds all the data like player position, and then a state machine/loop acts on and modifies this data. Is this similar to View Model/View Controller relationship? Wherein the View Model would control instantiation and data storage (the View), while the Controllers handle state?
Is this an accurate representation of MVVM, and/or is it a good design pattern for a game design?
Or put another way, what are the ways my representation differs from the paradigm, that I might want/need to alter?
Aside, do I use an additional "Controller" for physical/offscreen inputs (such as keyboard input), or do I put it in the View Controller? (With Javascript, detection of keyboard input will be tied to the View surface anyways (ex. canvas.addEventListener("keyup", func(ev)))
I hope that my text and graphical descriptions do not differ in their implications. If they do please let me know.
Update: 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. Anyways I'll gladly update this with a fixed diagram if anyone can help me get around my vast ignorance. I think this is a great way to show design patterns, if I only I knew what it actually was!
Best Answer
You're mixing MVC and MVVM here a bit.
Simply spoken:
The model is not only data. The model is your business logic. Most people get it wrong. It's not just a collection of data attributes encapsulated into classes, it is also behaviour.
Your thoughts are not so wrong. You want to put InputProcessors (You call them controllers) into your ViewModel. This is OK for a game, but if you want to implement the pattern as purely as possible, you'd bind keyboard commands to actions which are present in your ViewModel. So you'd bind them from concrete view (keyevent) to ViewModel(action).