4

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?

Improve this question

3 Answers 3

Reset to default
1

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.

Improve this answer
1
  • Didn't know the Memento pattern. That's a good hint.
    – Em1
    Commented Jul 31, 2014 at 15:45
1

I would have to agree with your colleagues. You don't want to mix View State information with your Model.

Right now you have 1 model and potentially many ViewModels and Views which are destroyed when closed, right?

It sounds like what you need is 1 model, 1 Parent ViewModel, and potentially many Child ViewModels and Views (which, again, are destroyed when closed). The key difference here is that the Parent VM doesn't get destroyed when the Child VMs do.

Its responsibilities include persisting View State between View instances, and also ensuring no two Views are showing the same portion of the Model (I believe that was one of your requirements?)

This helps keep your View State information separate from your Model and your "Undo" operations are relatively easy to implement.

Something like

  V     V     V
  |     |     |
  VM   VM    VM
   \    |    /
    Parent VM
        |
      MODEL
Improve this answer
2
  • From what I get, you would destroy the child vms. Then again you still run into the problem that there's no way of telling which scrolling position applies to which view. Or am I missing something?
    – Em1
    Commented Jul 31, 2014 at 14:44
  • Oh, and no, the views may show the same portion of the model. The user decides which part to show and if they scroll to the same position, that's fine.
    – Em1
    Commented Jul 31, 2014 at 14:45
0

If your view is complex and need to store some data, perhaps your view has a model, a model that belongs only to your view, of course. IMHO this is a different model from your core business model, complex applications can have multiple, independent, models.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.