Thursday 6 September 2007

What is the *exact* distinction between Model and View in MVC?

Couple of days ago, we encountered simple problem: Whether spreadsheet selection should be stored in model or in view. It seems obvious that the right place for it is the view, since data doesn't change with selection. Fine, but how do we know what the data is. In particular: how do we know that the selection is not part of it. I mean: It's clear isn't it. If it's clear, there should be a simple answer to the original question.

Quite an easy take is "data is what gets saved". Unfortunately, excel saves the selection along with the rest of the file. Since the saving criterion is useless, how about other apps using your data? Nope. There's nothing that prevents other apps from reading your selection state if it was saved. Our definition seems to escape.

Let me repeat what I want to achieve. Considering spreadsheet application: you got the model, which describes the content of each cell in each sheet, and you got the view, which tells you which part of the sheet you are watching right now. Since the view has a state, it needs to have it very own MVC to keep a track of it. So, what prevents us from merging view state (view model) into the data model (*the* Model)? The feeling, that it's wrong? Fine, but why you get that feeling? Why? WHYYYY? (this is the shot from 30 meters above [and receding] of a man on his knees crying in void. Never mind.)

Let's use maths. View is a projection of the real object (the data/model). Being a projection, it loses parts of the information. Does that analogy help us with the selection problem? Not really.

I spent some time thinking on this, investigating few other ideas, but in the end I gave up. I couldn't find any definition that was not tautological or simply wrong. The final conclusion is somewhat sad: there's no such thing as clear distinction. It's just like the zero being a natural number problem: it's a matter of taste, a matter of deal.

And why I had the feeling for obvious distinction? Most probably from the paper spredsheet analogy. Spreadsheets are so easy to grasp mainly because you can imagine them as pieces of papers.

More important consequence from that is that you'll never know if your MVC splitting was the right one. There are only practical issues. You may follow the way your brain tells you or not. You will never know if you were right. You will only know eventually that you were wrong. Now this is sad...

P.S. What makes life endurable here is agile appreach(yeah!), but this is a topic for other post.

No comments: