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.

Diagram depicting my understanding of MVVM Pattern

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!

  • Think about what an arrow means in your diagram. Does it mean a function call? Data flow? Event flow? Data ownership? I guess you are not using this in a consistent manner.
    – Doc Brown
    Sep 29, 2014 at 17:52
  • @Doc Well, if nothing else, I thought the representation was consistent, at least. Sorry! The arrows represent event flow. Sep 30, 2014 at 0:38

1 Answer 1


You're mixing MVC and MVVM here a bit.

Simply spoken:

  • In MVVM, you create an abstract representation of your View independent of the UI technology in use and bind your concrete (UI technology dependent- ) view to it with some sort of glue code.
  • MVC simply means: the view has a strategy pattern to communicate with the model and is an observer of the model. This strategy pattern is called "Controller"

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

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.

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.

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).

  • Thanks for the answer! I did already understand that the Model is the business logic, and so I updated the question to reflect that. Like, in a game, the Model would store the list of entities, but also would handle their AI. You can see me hinting at an understanding of that when I say I'd like to compare what I outlined to the game data. Anyways, is the Binder part of the View Model in the standard pattern? Could you provide some example of the structure similar to my diagram? I'm still not 100% on the specifics. Sep 29, 2014 at 15:53
  • I went ahead and accepted your answer but I don't have enough information to update the diagram so I may remove this question. Sep 30, 2014 at 4:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.