"Model" is itself data. More example, Model includes classes which describe the data, instance of those classes during runtime (some object graph) is truly the data. I think you should be more accurate in distinction of data. When you say "get data", and, say, "population", you might mean
persistent form of this data, database of some file(s) in some non-volatile storage. This detail goes beyond level of detail described by the pattern and is a part of Model, I would say, pretty marginal. Separate classes or not, depends on your own code design. In some complex situations, you may need to have a whole big abstraction level between your application and database, it could be even a separate tier. Or it could be a simple call to a serializer method. The MVVM pattern is abstracted from this detail, which is relatively trivial. The pattern is focused on like cycle and collaboration between UI, data and application state, as well as other patterns of this level, like
MVC and
MVP.
I think the roles or all parts of this
architectural patterns are explained clearly enough here:
http://en.wikipedia.org/wiki/Model_View_ViewModel[
^].
You should understand that patterns of this level is not very fundamental to computer science. It rather reflect cultural, social and commercial situation (be some natural historical reasons though), where we don't have any serious unification in the UI design and tools. UI tends to change more often then most people would like and UI frameworks are wildly incompatible between different platforms. All other parts of software are much more portable compared to UI parts. Such situation requires UI to be strongly isolated from other application aspects. All the pattern we discuss help developers to isolate big part of works from UI, make development smoother and, most importantly, to preserve heavy investment in software when people have to change the UI part again.
—SA