vendredi 17 mars 2017

Being new at MVVM and SOLID development, I’m working on a small WPF app, and I realized that my app is non-conventional in some ways:

All of my Model data needs to be refreshed very often either by polling (every second), or by utilizing callback functions (e.g. with Shell hooks and Automation events).
All refreshed data need to be pushed to the View immediately.
The View is strictly a display for the data; it doesn't expose any kind of data mutation feature.

Currently I’m using the following, standard MVVM/DataBinding solution:

My Model classes individually implement timer based polling or set up callbacks to keep their data up-to-date, and they implement the INotifyPropertyChange interface to notify the subscribers (the ViewModel) of all changes.
My ViewModel subscribes to the instantiated Model objects’ PropertyChanged event. The ViewModel also implements the INotifyPropertyChange interface, and when it receives change notifications from the Model, it issues its own change notifications for the View. (Most ViewModel properties are simply wrapping the same Model properties, but the most important data, a collection of items, is converted to formatted HTML string to use in the View's WebBrowser control.)
My View binds to the ViewModel as usual, and displays the updated data.

The app will work with this design, but it doesn't feel right.

Are there some known development patterns for these one-way display-only scenarios?

In particular:

Is it recommended to cut out the ViewModel, and expose all Model data specifically preformatted for the view? (No alternative views are planned for these data.)
Is it possible to extend a single base class or implement an interface that somehow helps to centralize the polling/callbacks/change-notification responsibilities?

This is how the unfinished/incomplete Model looks like now:

You can roughly see the current state of the dependencies. (I'm sure there are a lot of issues with this model.)

design-patterns