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)


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. — Preceding unsigned comment added by an unknown user 15 May 2006 12.111.164.21

That's Interesting! How is it you know enough to attack the original article but you can't write-up improvements/corrections??? Loon. — Preceding unsigned comment added by 50.37.105.71 (talk) 20:19, 31 July 2016 (UTC)

I Agreed, most likely that this wiki is controlled by fans. 200.73.30.108 13:27, 28 November 2006 — continues after insertion below

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. — Preceding unsigned comment added by 50.37.105.71 (talk) 20:19, 31 July 2016 (UTC)

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. — Preceding unsigned comment added by 200.73.30.108 (talk) 13:27, 28 November 2006 (UTC)

NO, the real problem is just like REST, people with weak experience start telling other people what something is without really knowing themselves. — Preceding unsigned comment added by 50.37.105.71 (talk) 20:19, 31 July 2016 (UTC)

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.

— Preceding unsigned comment added by 70.115.144.3 (talk) 04:15, 18 April 2015 (UTC)

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. — Preceding unsigned comment added by LuMo (talkcontribs) 07:52, 8 July 2016 (UTC)