I have an ongoing discussion with some colleagues on how to manage the views to our model.
We've got a model which may be represented by many views. Let's say we've got some data that is stored in an array and we'd like to display the data in a table and in charts.
A certain chart is unique but you're able to duplicate the chart. This duplicate should display the data in the very same way as the original, but it does not display the same part (e.g. if the data is too big to display it at once and you can scroll, so the original shows the first 10 items while the duplicated one shows the last 10).
At any time you can remove a view. The view and the view-model are then deleted from the memory. The model persists even if there's no view representing the data.
There is a handful of displaying information on the view which tells how and what part of the data is displayed. Scrolling is one of those, so let's stay with that example. This displaying information is neither persistent nor is it stored in the model.
If you shut down the application and restart, we don't care about how the view has been before and we always set up a default. If you, however, delete a view and then undo, we'd like to display the data exactly as it's been before deleting. The newly created view is technically not the same as before.
In order to adjust the view, I need to maintain the scrolling position.
I would simply put the displaying information into the model as this continued to exist for the whole time. However, some colleagues disagree and they say the model should only contain persistent data (like the actual data we're representing).
Hence we shouldn't keep track of the displaying information about the view in the model.
Q1: Is it correct from a design perspective that the model contains only persistent data? If yes, how would you maintain view-related information?
As said above, the model may be represented by many views, some of which may be duplicates of each other.
Let's say I found a way to maintain the data. I would have a collection of X displaying information.
Q2: When creating new views which actually replace the old views (keyword undo), how can I determine which displaying information of the collection should be associated to which view.
I mean even if my view had a unique ID, since we've created new one, we cannot rely on this data.
I can't quite figure out how I could associate these information correctly. The only idea that raises is having a separate view-model for each view and keeping the view-models alive, too. On the other hand, I think that's not what it's supposed to be, is it?
Best Answer
I fully agree with your colleagues that View state does not belong in the Model. That is what you have the ViewModels for.
To support an undo operation of closing a View, you could either keep the ViewModel of a closed View around until it is old enough that the closing can't be undone, or you can implement the Memento pattern to squirrel away the relevant View state in your undo list.