(I'm specifying this is a desktop application so people wouldn't refer specifically to web implementations of MVC).

The title says it all pretty much.

In an MVC structure - can the View ever hold a reference to the Model? Or should the Controller be used as a 'middleman' for communication between the View and Model - always - and in both directions?

If the answer is "no, it can't" - why?

  • One thing I learned from High School was that questions using absolutes were often 'false'. So that saying something along the lines of "A View may never hold a reference to a model' will usually be wrong to a certain extent. Therefore, I'm pretty sure a real answer will read, "You shouldn't ever do this, but I can think of a situation where it makes a little sense."
    – IAE
    Apr 6, 2014 at 22:07

1 Answer 1


The pattern you describe is what I know as MVP, Model View Presenter. This is an alternative to the MVC in that the Presenter contains the logic for updating the UI code without the View requesting the data from the Model.

The traditional MVC pattern does indeed allow for the View to know of the Model.

When to favor one over the other? Purists will argue that MVP is a much cleaner separation of both interface and responsibility. The argument goes that it's much easier to blur the line between querying the Model for any necessary data and being lazy and performing complex or even business operations in the View. Very ugly indeed.

Spoken as a pragmatic programmer, I did once create an Actionscript application where the view communicated indirectly with the Model via events. There was a certain class of ViewEvent or ModelEvent that only the View could receive or emit. This allowed me to get updates from the model without an explicit reference.

  • You might want to also include MVVM, which is the preferred pattern for WPF.
    – Andy
    Apr 7, 2014 at 0:06
  • Thanks for your answer. So basically, you're telling me there are two versions of the MVC: traditional MVC and MVP. The difference is that with traditional MVC, the View can hold a reference to the Model, while in MVP, it can't. In MVP, getting data from the Model in order to update the View is done through the Controller of the MVP (the Presenter), while in MVC, it's okay for the View to query the Model directly for it's data. The problem with the MVC is that it's easy to cross the line from only querying the Model for data, to actually call it's buisness-logic methods from the View, which
    – Aviv Cohn
    Apr 7, 2014 at 10:42
  • .. violates Separation of Concerns. So MVP is a more 'purist' approach to Separation of Concerns, while MVC is a little less strict. Is my understanding correct?
    – Aviv Cohn
    Apr 7, 2014 at 10:43
  • @Prog: MVC and MVP are two types of software-patterns, but there are more out there. Andy already mentioned that MVVM exists, which is a generalization of MVP, and there are others depending on the context. Check out RMR (Resource Method Representation) for the web and I believe Rails uses an even different architectural style.
    – IAE
    Apr 7, 2014 at 18:54
  • @Prog: Yes, the View can query the Model in MVC, but it is up to the implementer whether or not they would like to allow it. You can just as easily disallow or it abstract it as I did with my AS3 application. Your other points are pretty spot on for my understanding, but I'm hoping that another soul will answer so you have something to compare my answer to :)
    – IAE
    Apr 7, 2014 at 18:55

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.