I am currently working on a Windows Store application (8.1) which is supposed to do the following:
Now I am kinda stuck here regarding where to put the data. I use a Queue to store my values (I always want the last 100 values displayed). Now, what do I put into the model and what do I put into the ViewModel.
E.g. would I put the Queue containing the data points into my ViewModel? How would I trigger the process "Get some data every 1 second" correctly. I thought of using a System.Threading.Threads.Timer for that. Where would I put that? Into the MockDataServiceAgent? In that case: How do I access my ViewModel from the ServiceAgent to execute the update?
Everything is fine if you have buttons and stuff, but what if you have random events which are effectively triggered by "something else" than the view?
Your Model
is your domain object
, it represents the actual data
or information
you are dealing with. An example of a Model
might be that of a Car
containing a make
, model
, colour
etc. The main thing here is that the Model
maintains information
and not behaviour.
The ViewModel
is your presentation separation
layer, it can wrap one or more of your Model
objects. It is the glue between your View
and Model
exposing commands and methods which maintain View
state and can alter the state of your Model
as a result of actions
on the View
.
Your data
should be maintained by your Model
, or Models
. It would be your ViewModel
which would expose that data
and provide a mechanism for your View
to consume it. An ObservableCollection
is a common mechanism for exposing a collection of data
to a View
as it is dynamic and provides notifications when it has items added, removed or is refreshed entirely.
Ideally you do not want your objects to have strong links to one another, so to communicate between objects you might want to consider some implementation of the Mediator design pattern. Most MVVM frameworks have some implementation of this either as a Mediator
or EventAggregator
message bus. These provide a publish
and subscribe
mechanism where one object publishes
a notification containing some data and one or more subscribed
objects will receive that notification and process the data accordingly. None of the objects involved know who is a publisher
, subscriber
or who is involved, they only know of the Mediator
implementation.