Talk:Model–view–controller

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer science (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
 
High traffic

On 26 May 2010, Model–view–controller was linked from Slashdot, a high-traffic website. (See visitor traffic)

Confusing and Wrong[edit]

The first image that describes the MVC is very wrong. My understanding of MVC is that the Controller handles the program flow. For example: The user's response is accepted by the Controller. The Controller passes the info to the Model. the Model accesses Data and applies Business rules and the Model then passes back to the Controller. The Controller passes to the View. The View renders to an HTML page which is passed back to the Controller. The Controller passes or transmits the page back to the user.

So the Controller is central, and the various functions (Model, View, etc.) talk to the Controller.

However, the image shows the View passing back to the user. This is wrong and false.

I will leave it up to the editors of the page to correct this error. thanks — Preceding unsigned comment added by 167.102.133.216 (talk) 21:22, 21 November 2016 (UTC)


Resolved[edit]

What's up with that comment about GOTO's and globals? Who's implementation of MVC is that messed up?

The article only explains the benefits of the Model-View division. Not its extension to model-view-controller.

I have completed the merge from Model view controller triad. Also made some other changes:

  • Added brief intro: is it a design pattern?
  • Created benefits and liabilities section, moved platform independence discussion into subsection there
  • New liability: breaks encapsulation (ref Alan Holub's article)
  • Reorged SmallTalk refs into Implementation section
  • Added reference to Buschmann, et al.

Advantages and disadvantages[edit]

The only advantage listed is that MVC is more robust with respect to view instability than is having NO architectural separation of UI and business logic. And no disadvantages are listed, despite the section's name -- probably because nothing besides MVC is even mentioned. This section sorely needs some meat, I wish I had the knowledge to contribute it. That's Interesting! How is it you know enough to attack the original article but you can't write-up improvements/corrections??? Loon.




I Agreed, most likely that this wiki is controlled by fans.

So does this mean that you are now some how moral arbiters since you don't like MVC?? You wiki people are every bit as nuts as the media says you are. What a worthless pile of dung this has become.

There are (not exclusive) three "kind" of pattern idelogy, 3-tier, MVC and 3-layer and since different projects can have different trouble/needs, you must choice the best kind of model, not lets the model choose the workflow for you.

This models have their advantage and disadvantage, there was not a pattern that work for everything and MVC is not the exception. The real trouble with MVC is the lack of clarity with the concept, for example in some projects Model and Controller can be the same or view can be a blurry part of the model.

NO, the real problem is just like REST, people with weak experience start telling other people what something is without really knowing themselves.

Pure MVC (where data flows from model -> view -> controller -> model) has the following advantages:

  • Application behavior can be changed by modifying or swapping out the controller, without changing the model or how it gets rendered (view).
  • A single model can be displayed to the user in different ways/places by different view types.
 For instance, given a model that contains a list of e-mails, one view can display a list of the e-mails and their actual subjects, another view can just display the number of unread e-mails.  When a controller makes changes to this one model, BAM both views are updated
  • If you need to change all of the data a view is displaying, you just hot-swap its model.
 For instance if you have an e-mail content view showing the contents of an e-mail selected in a list view, whenever the list model says the selected e-mail has changed, view logic simply swaps out the content view's e-mail model, replacing it with the new e-mail model.

jQuery?[edit]

why is jQuery used as an example? can be done correctly in current javascript. since javascript is a known standard, using it as a basis seems common sense right. jQuery exists primarily because of the past nature of immature and conflicting implementations. seems to me that, with HTML5 coming into being, there should be no enforced reliance on jQuery, esp for purposes of illustration, when correct javascript will do.

Three tiers, three layers and MVC[edit]

What about following associations?

  • Presentation layer = View
  • Business layer (application logic) = Controller
  • Data layer = Model

Batch processing and MVC[edit]

Extend MVC to batch processing?

In applications that interact with users, with MVC or three tiers or three layers, the user sees the View and send instructions to the Controller through user events. It is possible to follow the same pattern for batch applications, even if these do normally not allow a user to participate. For example: a reporting program in batch:

  • Model: the data in files or in database, from which a report has to be extracted.
  • Controller: the reporting engine
  • View: the resulting report

We can extend report here towards an output file. The conversion of some input data to an output file can also be considered as a reporting or extraction process.

  • Model: the input data
  • Controller: the exporting, mapping and / or extracting engine
  • View: the output result

In the case of batch processes, there are normally no user events, and it is not user-event-driven. It is however possible that the database, file system or printer raise events or interrupts, based on the View (report, output data or output file), towards the Controller.

So in fact we could say:

  • Controller: manipulates the Model
  • Model: updates the View
  • View: presented to the user or output device = the addressee
  • addressee (user or output device): uses the Controller through events or interrupts

In fact, we could say MVCA, to include the addressee in the loop. But the A (addressee) is not part of the software.

Very Ambiguous Sentence[edit]

 A model stores data that is retrieved according to commands from the controller and displayed in the view.

This has several possible meanings:

1. a. - A model stores data that is retrieved according to commands from the controller 1. b. - A model stores data that is displayed in the view.

2. a. - A model stores data that is BOTH, retrieved according to commands from the controller, AND displayed in the view.

3. a. - A model stores data that is retrieved according to commands from the controller. 3. b. - A model stores data that is retrieved according to commands displayed in the view.

4. a. A model displays data in the view; data retrieved according to commands from the controller.

5. etc.

Fawby (talk) 11:39, 23 October 2016 (UTC)

honestly, you are turning words. Just use your common sense, and the context of the article. For example, have a look at the diagram located right next to the allegedly puzzling sentence. It is a closed circle, and the data and interactions flow from controller to the model to the view and to the controller and so on. And, in the given context, it is outright nonsensical to display commands in the view, since the whole purpose is to display and manipulate the data in the model. 93.104.7.42 (talk) 02:31, 19 November 2016 (UTC)