Model-View-Controller: who caches the data?

Question

I am building a GUI to interface an embedded device to a PC host. The GUI provides control over the device parameters and displays some feedback from it. The GUI also has to emulate some of the device functionality and present it to the user.

I have been advised to use a Model-View-Controller pattern, so that if the device does not acknowledge some command, the the user knows about the ineffectiveness of his actions.

Trouble is, I cannot decide which component(s) should cache data. Example: when a value is printed on the screen, the view clearly has to know it. However, the model also has to know it, as it uses it to calculate other values. Furthermore, the controller also has to know it as, for example, the value change could be proportional to a logarithm of the user action.

How do I pull this off properly?

• Machado: Is there any constraint requiring you to cache the data ? If not, than you shouldn't. Caching is another layer of complexity, and should be used only if the benefits surpasses the cost of using it.
• Vorac: @Machado, I need to cache the data, as communication with the device is expensive. My problem is how to cache it in only one lace, and not in each layer. Which BЈовић addresses quite well.

Answer 1

The view has to know it only in a way of how to show the information to the user. It doesn't really know whether it is a weather temperature, some random text, or anything else. It doesn't interpret data in any way.

The model is the one that stores and process data. And it knows whether to enable or disable a control. In your case, you need to cache data in the model.

The controller controls model and view layers. It is the one that can enable or disable a control in the view by using the value from the model. And it sets all the values in the view by just passing them from the model.

• btilly: Exactly. Caching is part of managing data and so is the responsibility of whatever manages data. Which is the model. (If it actually happens in a helper class, that fact should be still hidden behind the model.)

Answer 2

I would use additional Model (or Collection of those, which is again a Model) for cacheing. Then use event drivent architecture, where my View emits Events representing user interactions, to which my Caching Model would listen. The Model can emit events and so on. That way all components are nicely isolated and only communicate via events. And if Controller needs to do anything, again make it listen to events.

Answer 3

In such cases I think client side caching should anyways be used very carefully as it increases the chances of inconsistent data .

• gnat: this doesn't seem to offer anything substantial over points made and explained in prior answers