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?

2 Answers 2


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.

  • Thanks for the explanation. The last para summed it up for me. Commented Sep 11, 2013 at 12:02
  • So basically, for models we have to use the getters and do the calculation in the viewController in such scenarios. So, when I am writing a Unit Test for such functionality, I will have to test the Controller. Commented Sep 11, 2013 at 12:06
  • @AmoghTalpallikar: if you decide to put such a calculation in a controller, that is correct. But this is a case-by-case decision - view independent business logic should still reside in the model, otherwise there is a risk of creating a so-called Anemic Domain Model (martinfowler.com/bliki/AnemicDomainModel.html).
    – Doc Brown
    Commented Sep 11, 2013 at 12:32
  • I mean't small things like, say a model has a list of velocities recorded at different intervals in time. now a View wants display some graphic showing acceleration between two points in time. this logic should be in the controller right ? this is not model's responsibility to know that some view in future would like to show data based on averages of data it has. Commented Sep 11, 2013 at 12:58
  • 2
    It is not really an OOP way either that a view should tell the object (model/controller) what information it needs. It can simply query the model/controller. The "tell don't ask" principle is not about not querying, it is about not messing with someone else state. It means you don't "query state"-"evaluate state"-"change state" of another object, but that you "query state"-"evaluate state"-"tell to do something" and letting the object change its own state accordingly. Commented Sep 11, 2013 at 20:19

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.