How does MVC work with the principle "Tell, Don't ask"?

Question

Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.

— Alec Sharp

So, when a view wants to display some information that is suppose to be derived from properties of a model it is displaying, should the calculation be part of the model or the view?

Ideally the view should tell the object about the information it needs, and model should do the calculation and return the result.

But now, should the model start having new methods every time a new type of view wants to display extra information which is derived out of the model's property?

Should such methods be in the view or in the model? Or in such cases should we subclass the model, add the required methods, and then assign it to the view?

I am an Objective-C developer, I can also add a category to the model for the view but in languages where we don't have features where we can add methods to objects and classes at runtime, what is the ideal design?

Or are models in MVC meant to be just information in key-value pairs instead of real objects to be passed around, where a view reads each value based on a getter?

Answer 1

Ideally view should tell the object about the information it needs, model to should do the calculation and return the result.

That maybe an object oriented way, but not MVC. In MVC, the view typically sends a message to the controller "I want to display information", and the controller does the calculation using the model (or using model attributes or functions). Afterwards, the controller sends the result message back to the view (typically using an interface to decouple from the concrete kind of view).

but now, should model start having new methods every-time a new type of view wants to display extra information which is derived out of model's property?

Information derived out of model's property can be calculated either

• in the model
• in a controller using the model

I would place such calculation functions in the model only if they are not view-specific and have a certain chance of beeing reused. Functions totally specific to one view are better suited for the corresponding controller.

Answer 2

Actually, the "tell don't ask" principle does not mean that you cannot query an object about its state.

It means that you should not query an object's state and then change that object's state based on your own logic. That would mean the object (or its class) is not in control of its own innards, and you are doing open heart surgery where you should really only be a MRI scanner (or some such).

What you can do is query state, decide what that means to you, then tell the object to do something based on your logic and let the object take care of changing its state to reflect what was done.

In MVC a view does not have to tell a model what information it needs. Ideally a view is mostly passive. Telling the controller what the user has done and responding to update notifications from the model by changing the content of its controls.

The controller should control (!) the model based on what it was told the user has done (clicked a button). Usually the controller just conveys what happened to the model. It may query other controllers and models to decide how to handle what the user has done.

The model should respond to being told what happened (by the controller) by changing its state accordingly and sending out notifications to whomever subscribed to receive such notifications (usually the view will have been subscribed by the controller).

Please note that in MVC a controller can orchestrate multiple views on the same model, but you can also have multiple controller/view pairs working with the same model. This is for example how you would allow multiple views (sic) on the same document (for example an HTML view and a simultaneous raw text view).