3

In MVC the Controller is the go-between for the View and the Model. So the Controller should be the one that observes or receives changes from the Model and View and updates the other accordingly. I know for sure that doesn't break MVC.

But what if the Controller registers and unregisters the View as observer to the Model? What the view would know is the key path, what kind of change, and what the value is without having a reference to the model object. So if you assign model.title = @"new title" the View can map that property change to an action, like a UILabel subclass assigning self.text = @"new title". Does this break MVC?

4
  • What sort of breakage might you be referring to? Commented Jan 6, 2015 at 22:44
  • @RobertHarvey I mean breaking the MVC pattern where Views are supposed to be dumb about the Model Commented Jan 7, 2015 at 12:45
  • 2
    There's no such thing as complete decoupling. The View will always have some knowledge of the model, even if it is indirect knowledge through a ViewModel. How can it display the data from the model if it knows absolutely nothing about it? Commented Jan 7, 2015 at 16:37
  • 1
    Views are NOT supposed to be dumb about the model. It's an assumption that Models are dumb about Views, mainly because Views tend to be less stable than Models. That is, it's an architecture that allows View code to be changed easily without breaking the Model code. If you change the Model code, you will most definitely break the Views. It's often a point that is misunderstood in MVC. Commented Jan 8, 2015 at 13:55

1 Answer 1

4

No, having the View observe the Model (or perform other read actions on the Model) is a valid implementation of the MVC pattern.

There are two main ways that the MVC pattern is typically implemented and they differ mostly in how the information from the Model gets to the View.

In the first form, all information passes through the Controller, who is made responsible for feeding the View with the information it needs and to transform complex data structures used in the Model (like classes) into simple arrays/dictionaries that the View works with. This form is fairly popular with web frameworks with the philosophy that UX experts with limited coding experience can create the Views.

In the second form, the Controller might connect the View and the Model with each other, but the View itself determines which information to retrieve from the Model. In this form, the View can also observe the Model and be notified of changes without the Controller being involved in the update. I would expect this form more with interactive (non-web) applications.

3
  • Ok, so the Controller needs to be the one to register/unregister the observation and in that way the View and Model are dumb about each other's existence and get informed of the information changes only Commented Jan 7, 2015 at 12:51
  • 1
    @KoreyHinton: The Controller doesn't even have to be the one that makes the registration. The only thing the Controller really needs to know about is the information that the user can change. The Controller isn't required to know about information that is presented but can't be changed. Commented Jan 7, 2015 at 12:56
  • Good point, the View can display static content the Controller doesn't care (or know) about. Commented Jan 7, 2015 at 13:17

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.