3

I am currently working on a Windows Store application (8.1) which is supposed to do the following:

  • Talk to a USB HID Device (figured that out)
  • Display data from that device (I want to use Oxyplot for displaying this data, got that)
  • Use MVVM (I selected SimpleMVVM toolkit since it already has templates for VS2013)
  • Create a mock data provider which generates random data and feeds it to my ViewModel

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?

Tom L.
  • 932
  • 2
  • 9
  • 30

2 Answers2

3

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.

  • Thanks for your response. I understand that in my case I should keep the ObservableQueue (I implemented an ObservableQueue which is a Queue with added notification) in my ViewModel. The data itself (DataPoint class) is stored in the model. I found that SimpleMVVM also has some sort of Mediator pattern available (RegisterToReceiveMessages, SendMessage). One thing which I cannot understand yet is where would I put my timer which either fakes or retrieves real data. Should I place that into the ViewModel as well an then get data from the MockDataPointServiceAgent? – Tom L. Nov 30 '13 at 12:06
  • @TomL. Your `MockDataPointServiceAgent` is responsible for providing the `data` you consume, therefore I would place the `Timer` in there and then use the `Mediator` mecahnism to `publish` the data. Notifying others that new data is available is generally a better idea than polling as you might poll 100 times, but only get new data 1 time. –  Nov 30 '13 at 12:08
  • That's what I wanted to do first when I stumbled upon the fact that the ServiceAgent is NOT derived from ViewModelBase (which contains the mediator pattern functions). Now I would have to derive the ServiceAgent from ViewModelBase which I find not very clean. – Tom L. Nov 30 '13 at 12:17
  • @TomL. I see your quandary and agree, that does not seem clean. It is not too complicated to knock up your own `Mediator` implementation _if_ you felt so inclined. –  Nov 30 '13 at 12:32
  • @TomL. An alternative, have your `ViewModel` constructor require an implementation of `IDataPointServiceAgent` which exposes an `EventHandler` delegate that your `ViewModel` can hook into directly for data `push` notifications. This would mean that your `ViewModel` has a dependency on `IDataPointServiceAgent` however, that might be acceptable in your implementation. –  Nov 30 '13 at 22:46
  • Thanks, that's a great idea. I think I'll go with this approach. – Tom L. Dec 01 '13 at 06:42
1

You could put your queue containing the data in your ViewModel, as an ObservableCollection, then when the ObservableCollection is changed it can update whatever it is bound to. It would be best to keep the link between the ServiceAgent and ViewModel loosely coupled, I would suggest using SimpleMvvm's messaging system, if it has one, I know MvvmLight (another Mvvm toolkit) has one. Or you could build one yourself by using the Mediator pattern. Or if you don't want to use a Mediator, use an IoC Container. Just get your data service process to update the ObservableCollection, and that should cancel the need to worry about events (for updating the UI).

Cloud9999Strife
  • 3,102
  • 3
  • 30
  • 43
  • Thanks for your comment. If you were me, where would you put the timer which retrieves data (or fakes it)? – Tom L. Nov 30 '13 at 12:06
  • I would place it in the DataServiceAgent. – Cloud9999Strife Nov 30 '13 at 12:13
  • That's what I wanted to do first when I stumbled upon the fact that the ServiceAgent is NOT derived from ViewModelBase (which contains the mediator pattern functions). Now I would have to derive the ServiceAgent from ViewModelBase which I find not very clean. – Tom L. Nov 30 '13 at 12:18