title: Role of the model in a "traditional" C# / SQLite MVVM app
body: <p>Based on a response in <a href="https://stackoverflow.com/questions/25499037/mvvm-observablecollection-async-etc">a separate thread</a>, I'm concerned that I have missed a basic principle of MVVM as I learn this stuff. I get the easier stuff about the view binding to the view model, notifications, etc. The underlying technical aspects make sense to me. What is less clear is where the boundaries exist between the viewmodel and the model.</p>
  
  <p>I am trying to build a universal all (with my focus right now being on the Windows Phone part). I will use SQLite to persist and retrieve data. And that simple aspect is where I am not clear.</p>
  
  <p>I had assumed that classes I write will form the "model" and those classes would be responsible for retrieving data from SQLite. The viewmodel would bind to properties on the model classes and the view would bind to properties in the view. As part of all this, it was my assumption that all the interaction with SQLite would be in my model.</p>
  
  <p>Now, based on a comment in a separate thread, I fear I have that wrong. The statement was that the viewmodel would be responsible for "loading" the model. It - not the model - would presumably interact directly with SQLite.</p>
  
  <p>Well, that threw a spanner in my understanding and now I wonder if I missed the wood through the trees all along :) In my simple app what is the model layer? Can SQLite itself be considered the model, with the viewmodel interacting directly with SQLite. If so, what's the role of model classes I might write - if my needs are simple (CRUD into SQLite), so I NEED classes at the model layer?</p>
  
  <p>While I know there's no one "right" way to design such an app, I want to make sure I follow basic, accepted principles. With that in mind, in a "simple" MVVM / SQLite app, what is exactly IS the model later?</p>
  
  <p>Thanks</p>