tags:

views:

134

answers:

5

My question is about the ideal or the original MVC interpretation http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

As MVC goal is to reduce dependencies, should the View knows the Model ? Then what would prevent it to become fat and call directly Model Methods without asking Controller ?

Update: as I read answer below, I'll take a concrete example:

Let's say you create a complex calculator (not just some simple one let's say an option pricer for stock market). It only needs input like stock price, interest rate, volatility. So why would I create a reference to the whole model which contains the methods from the view since I ONLY need these input variables ?

Why the controller would not just be notified when something change in the view and then callback a method in the view with the input only ?

For example here I see the View has a reference to the whole model:

http://leepoint.net/notes-java/GUI/structure/40mvc.html

private CalcModel m_model;

+1  A: 

Yes, in MVC the view knows about the model. In fact, the view's job is to display the model so it has to know about the model. The models should be fairly simply and shouldn't pretty much be containers of state (i.e., properties that are strings, ints, etc.) - it shouldn't really have methods.

The controller knows about both the view and the model - the controller's job is to get the appropriate model and pass it to the appropriate view.

The model should be blissfuly unaware of either the controller or the view.

This is the typical Separation of Concerns in MVC (SoC) where each component has its well-defined "job".

Steve Michelotti
Displaying the model doesn't mean it need to know the WHOLE model, just the datas to show. A model OBJECT is much more than just data: it contains also methods.
"it contains also methods" - that's subjective depending on who you ask. :) Also, typically we use "view models" which contain *only* the data that you want to display. This may or may not match your domain model 100%.
Steve Michelotti
Then I reference the original inventor of MVC http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html is it still subjective :)
Yes, it is still subjective. Patterns are made to be adapted over the years and you see tons different "flavors" and implementations for MVC across the technology spectrum. Patterns are never one size fits all.
Steve Michelotti
+1  A: 

In MVC the point is not that you should not comunicate between M-V-C. The point is to keep the model seperated from the view (and the controller) so you can change/substitute the components easily.

http://en.wikipedia.org/wiki/Model%E2%80%93View%E2%80%93Controller

PeterMmm
+6  A: 

The view should not know about the business model, that's up to the controller. The view should however know about the data model. How else must it present it?

BalusC
so concretely what does it mean ? Would you create a reference to the whole model class in the view or just a reference to a data structure that would be passed by the controller to the view ?
The view doesn't create the data model, the view just accesses/uses it. So, it's the latter.
BalusC
the controller gives the model to the view. The view has no idea where this data comes from, just that it is to render it. If "the model" has methods, etc, then it is doing too much.
matt b
@BalusC Then could you confirm this example should not be followed: http://leepoint.net/notes-java/GUI/structure/40mvc.html as it has a reference to the whole object model ?
@matt b If "the model" has methods, etc, then it is doing too much ? I don't understand your remark. The model is NOT just the data. What I have learnt is rather If "the CONTROLLER" does too much then it's evil since the controller is only supposed to just redirect command.
@user: the view has a reference to the model to display the data. The view hasn't created it. The view doesn't invoke action/business methods on the model. The controller does that. The view only accesses data methods (usually getter methods) to get data for display. Further, there must be taken care with ambiguity in "model" (business or data). The linked example has business and data model tight coupled in a single class.
BalusC
Should probably note that the definition of roles of the MVC components tends to differ from GUI applications to web apps
matt b
+1  A: 

Then what would prevent it to become fat and call directly Model Methods without asking Controller?without asking Controller?

I found this to be a bit humorous. Views don't have minds of their own, but programmers do. They're the ones that make bad decisions and give permission for View to do what it does.

View has to know enough about Model to be able to display. If your programmers can't control themselves, one answer might be to make their Model objects immutable.

Another might be to use AOP. Write an aspect that prevents calls to the service layer that don't come from either other services or controllers.

There's one other point of view: AJAX is all about Views taking things into their own hands and making calls to services, without permission from anyone, to do things asynchronously and improve responsiveness for a better user experience. That's a good thing.

Don't be too hung up on architectural purity. MVC is a fine pattern, and very useful where it applies. Know the rules; know when it's appropriate to break the rules. Don't be so dogmatic - in programming or in life.

duffymo
How can you make Model objects immutable if you need to modify the model before persisting it in database for example ?
As I said above why pass the whole model ? Why not just the dumb data to show ?
@user310291 - This is where you end up with parallel mutable and immutable hierarchies of objects. Business objects and DTOs. I'm not saying that I like the design, but people who care a lot about "layer purity" will often opt for it. That's what you're idea of passing "dumb data" instead of the whole model sounds like to me.
duffymo
I can't see why you'd need to create immutable stuffs if the controller is notified by the view and then pass it back the dumb data ?
Then you don't agree with BalusC ?
Immutable means "can't change; can't do anything with". It's one way to make sure that the view only displays data. And as for BalusC, I think he's a very smart man. I'm not sure why you think we disagree. I say that I'm not as worried about passing model objects to views for diplay. If the view isn't supposed to do things inadvertently, then don't code it to do so. I don't necessarily believ that naggy, nanny-ish code to strictly enforce it is necessary or desirable.
duffymo
A: 

The goal of the view is to render data derived from the model. So the answer is it should not. On the other hand the model should not care how those data will be presented.

For instance, the business logic might have been:

  view->report->annual_revenue =
    this->first_quarter_rev +
    this->second_quarter_rev +
    this->third_quarter_rev +
    this->fourth_quarter_rev;

While the presentation logic:

  if (!this->report->annual_revenue) {
    print('No information')
  }
  else {
    print(format('# ###', this->report->annual_revenue) + '$');
  }
Gustav Calder