According to the wikipedia page for the MVC architecture, the view is free to be notified by the model, and is also free to query the model about its current state. However, according to Paul Hegarty's course on iOS 5 at Stanford, lecture 1, page 18 all interaction must go through the controller, with Model and View that are never supposed to know each other. It is not clear to me if Hegarty's statement must be intended as a simplification for the course, but I am tempted to say that he intends the design as such.

How do you explain these two opposite points of view ?

10 Answers 10


This is a controversial topic in MVC/MVVM. Some say it is OK for the View to access the Models directly, other say you should wrap the Models in ViewModels in order to abstract them away from the View. I'm personally not a fan of either approach.

The one of the primary goals of MVC/MVVM is to decouple the UI, business logic and data. So with that concept in mind, allowing the View to directly access the Models creates a dependency that you might not want to have. On the other hand, wrapping the Models in ViewModels is often tedious and not very useful as the ViewModels tend to act simply as a pass-through to the Models.

I like the approach of having your Models implement a particular interface, lets call it IModel. Your ViewModel class can then offer instances of objects that implement IModel for View consumption. The View simply knows it works with IModel objects that it gets from the ViewModel. This removes the extraneous ViewModel wrapper code as well as hides the concrete implementation of IModel from the View. You can later swap out one implementation of IModel for another without affecting the View one bit.

  • 1
    In regards to the tedious aspects of mapping a model to a view model it should be noted that there are tools that are available that can ease the mapping pain. EG: (.NET AutoMapper) (JAVA modelmapper)
    – Jesse
    Commented Feb 16, 2012 at 17:18
  • +1 Great answer! This is a great approach depending on the complexity of your model, but most models today are of the Anemic type. Elements of the model, being little more than data objects without behavior, I see little to no need for such an abstraction and little danger in allowing your View to access your Model directly.
    – maple_shaft
    Commented Feb 16, 2012 at 18:43
  • 2
    I hear what your saying; most IModel interfaces would simply contain a bunch of property declarations and few (if any) method declarations. But even if the Models are anemic, the interface still decouples the View from their concrete implementation. This separation may not be necessary for every project, but it's always a good idea to keep your options open. Commented Feb 16, 2012 at 18:58
  • 2
    I'm confused, if you have a bunch of views that are absolutely different how can you rely on an interface without cluttering it up ? I think View Models are fantastic.. You create Models which are generic enough to be used through out your application and you create View Models to consume one or more Models and additionally implement operations that would only be used by that view. Commented Feb 22, 2012 at 9:07
  • One concern that comes to mind is that it's common for the interfaces for models and view models to change at different rates. For example, a view model and a model might both start out using a string representation and then later the backend switches to an enumeration. The backend should be able to evolve without the UI interface needing to change. It's easy for a developer to accidentally use refactoring tools in the backend and suddenly the front-end stops working because the JSON model is incompatible. 😬 Commented Apr 22, 2021 at 14:42

On the web, everybody calls their decoupling MVC.

Some technologies, such as C#, use MVVM because there is no link between the View and any other, everything goes through the service locator, binding the variables.

On pure MVC, the View talks directly with the Model and vice-versa. The Controller is only there when any change arises.

And then, there is the one called PAC (Presentation Abstraction Control). In this architecture, the View and the Model don't talk to each other. The Controller is the only one allowed to do anything with either the View or the Model. People often confuse this with MVC.

You'll see a way better explanation here : http://www.garfieldtech.com/blog/mvc-vs-pac


In MVC, Paul Hegarty is wrong. Controller is about user events, not model-to-view communication. In classical MVC, the view(s) observe(s) the model (Observer pattern).

With the guy in between doing the mediation, the pattern should be called MVP, and in fact, most of what is nowadays presented as MVC, is in fact nearer to MVP.

Then there is MVVM which is something similar to both, and yet a bit different, and existed long time ago... it is best to see it as two MVCs/MVPs bound together through viewmodel object - the "client" MVC has viewmodel as its model, and the "server" MVC has the viewmodel as its view.

  • 1
    Today (early 2014), to me (with my node and angular stack) this distinction on "client" MVC and "server" MVC seems very relevant and somehow enlightening. (thank you) Commented Mar 5, 2014 at 16:27

For me, the basic goal of an architecture is that it not impede future attempts at refactoring. Typically, views interacting directly with models jives with this requirement, and it's relatively clear when it doesn't.

When a view is becoming too intimate with a model, a ViewModel can be a beautiful thing, but it's usually the case for me that the instances where it's called for are in the minority.


Since you're asking about the material in those Stanford lectures in particular, It's worth considering two things about Hegarty's stance:

  1. As you've mentioned, he's teaching a l00-level Computer Sci course. There are plenty of places in his lectures where he simplifies, glosses over details, or says "just do it this way", as one probably has to when teaching the basics, i.e. you have to master the rules before you can break them.
  2. My experience with the iOS SDK is that, where it doesn't enforce strict separation between View and Model, it is geared heavily towards that pattern. When writing iOS apps in particular, adhering to model-view separation helps you write code that's in line with the framework's expectations. I'd hesitate to generalize Hegarty's statements to development on other platforms or in general.

I do agree with Paul Hegarty and believe that the View must not know about the Model. It is not that difficult to achieve but it brings additional benefits to your design and future flexibility.

In small applications (usually desktop) where I would like to avoid "dummy" ViewModel classes and keep things simple, I do also use IModel interface (see the answer above) and do take care that Model has no idea about the View (use subscribers as in the classical MVC).

Also in this case the Controller is turned to be quite coupled with the View and for simplicity I do not always clearly separate them.

The second “simplified” approach is OK when you may have several views for the same model, but I would not recommend it if you would like to use the same view for different models. Under different I mean really different by nature and not just JUnit test classes that “follow” the main model.


I believe that there is not hard and fast rule for this, it totally depends on your needs.

You will find people with different beliefs. Architectures are concepts to help design better solutions.

Apart from model-view communication, there is one more contradiction about the business logic in MVC. Many people believe that all the business logic should be one model (see this SO question), on the other hand the link shared by Florian (in his answer) says business logic should be on controller.

Apart from this there is a possibility of dividing the business logic into Application logic (put it on controller) and Domain login (put it on model).

So, the moral of the story is MVC means model, view and controller should be separate. Other than that, whatever suits you best.


I use DTO for model-view communication.

For instance:

  • User fills the Update Form (View)
  • User sends form
  • Controller binds form data to UserUpdateDTO
    • DTO and UserModel are POJOs but DTO has no id and username because we cannot update username.
    • Another difference is Model class has relations and associations but DTO stores only data and we may add JSR 303 validators to it
  • Controllers says it to service layer to save
  • Service layer says to DAO layer to persist the data

I am with the camp that says that the view should never communicate with the model. The controller must always be the go-to guy for everything, it then decides what to do (validate, ask for data from the model, etc).

I tend to see it more as an organizational issue that anything else.


As many are suggested on why and how view & model should have to interact freely in different contexts, but the main reason in iOS for making Controller is the mediator between them is to avoid Model & View dependencies in your code base and allowing us to reuse either model or view according to requirements with the evolving of iOS.

As we might need to keep updates to our Apps in UI/UX or Model or some times both, it should not produce mode dependency code between model & view.If you want to change the Presentation layer of your app, then you just go and change it then you can still reuse the same Model and vice versa can be done.

Though i agree that MVC in iOS produces giant ViewControllers with lots of various logics in it and handling every kind of stuff other than what it is intended for.So its better to go with MVVM or Presentation Controls to make your code base more flexible, easy to read and maintainable with smaller ViewControllers.

This might help who are looking for smaller ViewControllers in iOS:


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