9

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;
tereško
  • 58,060
  • 25
  • 98
  • 150
user310291
  • 36,946
  • 82
  • 271
  • 487

5 Answers5

19

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?

See also:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • 1
    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 ? – user310291 Sep 18 '10 at 14:41
  • The view doesn't create the data model, the view just accesses/uses it. So, it's the latter. – BalusC Sep 18 '10 at 14:43
  • 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 Sep 18 '10 at 14:51
  • @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 ? – user310291 Sep 18 '10 at 14:52
  • @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. – user310291 Sep 18 '10 at 14:54
  • 2
    @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 Sep 18 '10 at 15:08
  • 1
    Should probably note that the definition of roles of the MVC components tends to differ from GUI applications to web apps – matt b Sep 18 '10 at 16:26
9

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
  • 305,152
  • 44
  • 369
  • 561
  • 1
    How can you make Model objects immutable if you need to modify the model before persisting it in database for example ? – user310291 Sep 18 '10 at 14:45
  • As I said above why pass the whole model ? Why not just the dumb data to show ? – user310291 Sep 18 '10 at 14:46
  • @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 Sep 18 '10 at 15:03
  • 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 ? – user310291 Sep 18 '10 at 15:12
  • Then you don't agree with BalusC ? – user310291 Sep 18 '10 at 15:13
  • 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 Sep 18 '10 at 17:51
4

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
  • 5,223
  • 1
  • 25
  • 30
  • 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. – user310291 Sep 18 '10 at 14:43
  • 2
    "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 Sep 18 '10 at 14:49
  • Then I reference the original inventor of MVC http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html is it still subjective :) – user310291 Sep 18 '10 at 14:59
  • 2
    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 Sep 18 '10 at 16:11
1

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
  • 24,152
  • 13
  • 73
  • 111
0

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) + '$');
  }
Agent Coop
  • 392
  • 4
  • 12