2

I'm learning MVC to develop a website, and I'm finding confusing the (apparent?) differences from the "theory" and the current widespread implementations.

In the original and Martin Fowler's article the MVC concept seems to favor a "smart" View, which interacts directly with the Model to retrieve the data to display, and decides by itself how should the data be presented. On the web, that should be the output format (HTML, JSON, PDF, etc).

On the other hand, the View in current frameworks like ASP.NET and Zend seems to be little more than an HTML template.

This to me raises a question: I can create a View for each format, but then where should I in these frameworks decide what View to display? Should the controller decide which View to load? But then, is it the controller's responsibility to know the right format to display? That seems to be against the theory.

What is your experience when using MVC and you need to output different formats?

skaffman
  • 398,947
  • 96
  • 818
  • 769
André Paramés
  • 934
  • 9
  • 23
  • Well, usually actually the request object decides. You get the request object in the controller and based on the parameters you pass the correct objects/variables to views. It is often good to have just one view for displaying lots of different but similar pages (if the HTML is 80-90% the same there's no point in redundant view scripts, just use simple if/else etc in view scripts to decide what do display). That's how it is done in most frameworks, whether it is theoretically sound, I don't know. – Richard Knop Nov 04 '10 at 10:10

3 Answers3

1

I think you're missing the fact that the Views in current frameworks do a lot of the work to communicate with the model to retrieve the data to display, and which are fundamentally modally locked (i.e., the HTML View fundamentally displays HTML, etc.). The concept of a "smart view" which determines how to display the data is a little bit muddled, as well; for example, in ASP.NET MVC, the Views will actually render your HTML differently based upon what browser the user is using, so there's a bit of that, but they don't go so far as to completely change the mode in which the data is presented (visual vs. auditory, for example).

Paul Sonier
  • 38,903
  • 3
  • 77
  • 117
0

My experience with a true MVC is limited to the Zend Framework and I'm still pretty green. But this is my opinion(for what its worth):

In Fowler's article, he describes an MVC where where the C and V are completely unaware of each other. It is widely excepted that the C and V can interact. See Dean Helman's explanation and ZF's explanation.

It has been my experience that the controller can tell the view, for example: "I want this data as JSON" or "Add this data to the navigation" or "Here is the data, I don't care what you do with it."

EDIT: I think you may be confusing MVC with MVP. See What are MVP and MVC and what is the difference?

Community
  • 1
  • 1
Fatmuemoo
  • 2,187
  • 3
  • 17
  • 34
-1

There is whitespace which joins M, V and C and this is also very important.

What's this V is for? Are view helpers that access models M or V? Are layouts or placeholders too?

There is no strict definition, and nobody expects strict one. It's all about the separation, and it may vary how strict it is.

As Fatmuemoo noticed it may be you confusing, or maybe the frameworks or Fowler is.

What's the difference is one makes controller decide, other one view helper do. But the real thing is the request decides. You may process it before rendering the view or after, depending what do you want to do, and it is still MVC.

Community
  • 1
  • 1
takeshin
  • 49,108
  • 32
  • 120
  • 164