0

So let's take that simple example:

data --> projection --> view

What I call projection here can be any UI state resulting in filtering, sorting, highlighting, etc...

In an MVC paradigm, data lives in the model, view is the view, where does state belong?

I used to store state in the controllers but I've heard it's bad, controllers should be kept "lean" and everything should be stuffed into the model. I can see the advantages of having stateless controllers for testing but it seems counter intuitive to couple the data and its projection in the model.

What if different views want different projections of the data? How does it break down?

[EDIT] Found some related questions here and here but they don't answer the question directly. I know to put the logic for projecting the data inside the model but it doesn't say where the state of these projections should be maintained.

Community
  • 1
  • 1
Renaud
  • 4,569
  • 7
  • 41
  • 72

1 Answers1

1

The "projection" you are talking about is one of two things. Either it is actual model data, at which point it belongs to the model layer, or it is a ViewModel in MVVM. As such, it lives in it's own layer between view and controller.

I would really need to see more details to understand which of these is a better representation of what you are trying to accomplish. For example, if this is storing the state of the checkboxes, and the text fields, then it is MVVM. If you were recording a list of entities that were "selected", then it probably belongs down in the domain layer.

If it is it's own model, it might not live in the same model as the original. It could be completely separate, but still depending on the other model.

Rob Conklin
  • 8,806
  • 1
  • 19
  • 23
  • I'm working in a data visualisation context and the projection is a processed version of the model, kind of a cache I guess. ViewModel seems like a good fit here. Is it compulsory to have one or can the view access the model directly in MVVM? – Renaud Sep 03 '14 at 12:05
  • When you say "processed", it makes me think that it's still a model, just a different representation of that model, and thus should still live in the model layer. If you haven't "processed" it into objects that are specifically tailored to your particular view, then it's just a straight model, which makes the decision easy. – Rob Conklin Sep 03 '14 at 14:18
  • Don't conflate a cache with a different representation. If you ever expect the object to be there in session, then it's not a cache. – Rob Conklin Sep 03 '14 at 14:23
  • That's what I ended up doing indeed: I broke the model down into submodels and it works nicely. Do you want to update your answer so I can accept it? – Renaud Sep 04 '14 at 12:37