My senior reviewer colleague wants me to do the following.

We have (on iOS, iPhone) a hierarchy of views in one of our screens. There is a simple rectangle that represents a Business card of a person (visually matches business cards style).

As this card is reused many times in many screens, I have written a custom class called PFXBusinessCard that has four labels, each label representing person's data like Name, Phone number, account and email. These four labels are exposed as properties of that custom class.

In my controller, I am passing the data for a particular label in a following manner. I get the person, read the particular value for a property and set this property in a controller. That is, I am setting the name, phone number etc..

But my colleague says I should instead handle this inside the PFXBusinessCard class. I should create a populateWithPersonsData method in the class, and I would just pass a person to the card in my controller. The card would then populate its labels itself.

Is this approach ok? Why would the card should know about the person? The UI object should not know anything about the data. Should it?


This is an issue that can be debated forever and in the end, both sides might be right.

There are two schools of thought in the application of the MVC pattern, which is what your question boils down to. I would name them the schools of the dumb View and the smart View.

In the dumb View, the View should concern itself only with UI matters and should not contain any logic (with the possible exception of iterating over a collection of values it needs to show). The controller is responsible for handing the data in bite-sized chunks to the View.

In the smart View, the View is allowed to have a limited amount of logic in it. In particular, the logic to convert objects from the Model into displayable values.

In my opinion, the smart View most closely resembles the formulation of the MVC pattern and should be preferred. It seems to me that the dumb View came about because for some it was too tempting to put business logic in the View (which does not belong there) and because it seemed that the Controller was losing its function.

  • I'm not sure if BusinessCard is a parent class of PFXBusinessCard or if it is the model, but if it is the model, adding a method in the model for populating the view is most certainly wrong. – Neil Apr 24 '13 at 10:31
  • @Neil: I agree. The Model should not know about the View. I understood BusinessCard to be part of the View and Person the Model class that the data comes from. – Bart van Ingen Schenau Apr 24 '13 at 10:34
  • Just saying. Your answer isn't wrong because it wasn't really specified one way or the other. Just wanted to note for anyone reading. :P – Neil Apr 24 '13 at 10:51
  • It was just a typo - missing prefix there...all the time, I am talking about the UI component called PFXBusinessCard. – Earl Grey Apr 24 '13 at 12:24

What if you create category

@interface PFXBusinessCard (PersonData)
- (void)populateWithPersonsData:(PersonData *)personData

so your View class is not aware of Model class, but all this logic is still encapsulated, and you keep it DRY. It's subject to discuss.


The card should know the person if displaying the person data is one thing it will do. Your colleague is right IMHO, because there must be logic for displaying PersonData somewhere in the whole code base. If controller wouldn't do it, so it belongs to the consumer of caller to map every properties of PersonData to your controller, and this logic will be scattered in your codebase. Any OOP design should bring more quality to the overall codebase, not reducing it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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