Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 ?

share|improve this question
add comment

9 Answers

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.

share|improve this answer
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 Feb 16 '12 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 Feb 16 '12 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. –  Ray Saltrelli Feb 16 '12 at 18:58
    
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. –  The Muffin Man Feb 22 '12 at 9:07
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.
share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

The model with the guy in between doing the mediation, the pattern should be called MVP, an 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.

share|improve this answer
    
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) –  jaywalking101 Mar 5 at 16:27
add comment

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
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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