Here is an issue I’ve confronted in multiple user-facing applications: a program contains components for graphical rendering of data, (call them views) and other components for managing those data (call them models). Some of those data are in the form human friendly text, often key value pairs such as
System Load: 20%
Running Time: 20mins 30sec
But which software component should be responsible for constructing the text strings? You could argue
-
The model: should choose the text while leaving the view to display it. This way the views don’t have to know exactly which data are provided, and (probably) lets the model expose only a small API. Also it means that the text stays consistent across multiple views (or UI toolkits). This ways views don’t have to worry about i18n.
-
The view: should do it because this is a UI issue, not part of the business logic. After all, the choice of text is not always cleanly separable from rendering. This way models don’t have to worry about i18n.
How should I settle, or think about this division of labour? Any ideas?
Note 1: I don’t think this issue is restricted to MVC designs, although that’s where I get my terminology.
Note 2: While researching this question I stumbled across Presenters, and ViewModels. Are they supposed to do this kind of work, and when is such a proper/complicated solution worthwhile, and when is it OK to just do it in the Model or View.
Taking this from an MVC perspective, if I have data to display in my view I will (almost) always create a viewmodel which the view inherits from, with the viewmodel properties of the correct type for the data. e.g. in your example above I would have SystemLoad as decimal, and running time as a number of seconds. I believe it is then the responsibility of the view to determine how that data is displayed (how the user VIEWS it).
Using the ViewModel approach makes it very easy to define multiple views to represent the same data. A controller need only know to supply and receive a specified class – the ViewModel – which can then be passed to whichever the most appropriate view is to be rendered. This rendering could be rich HTML for full browsers, stripped down for mobiles, or even a JSON response for an API, either way the controller need not change.
WRT to the original question, this is just an example of justification for leaving the formatting to the View. Whether you use viewmodels or not, this logic does not belong in the controller