Talk:Model–view–controller
The subject of this article is controversial and content may be in dispute. When updating the article, be bold, but not reckless. Feel free to try to improve the article, but don't take it personally if your changes are reversed; instead, come here to the talk page to discuss them. Content must be written from a neutral point of view. Include citations when adding content and consider tagging or removing unsourced information. |
This is the talk page for discussing improvements to the Model–view–controller article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1, 2Auto-archiving period: 30 days |
Computer science Start‑class Mid‑importance | |||||||||||||||||
|
On 26 May 2010, Model–view–controller was linked from Slashdot, a high-traffic website. (Traffic) All prior and subsequent edits to the article are noted in its revision history. |
Resolved
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
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.
I Agreed, most likely that this wiki is controlled by fans.
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.
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?
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.
Confusing inaccurate and badly written article
What makes the article confusing I think is that it doesn't define the M, V and C in a clear and concise way. Basic on the diagram it implies that user interaction goes from the User to the Controller directly which isn't the case. Whatever you'd like to call it, perhaps "the glue", the User interacts with a GUI and whatever actions they perform don't automatically delegate to a Controller - the glue makes it happen. Now, if the controller is responsible for setting up the glue, then it also must know completely how the V is constructed - Some framework implementations seem to tightly knit their M, V and C (Microsoft MVC being an example), however it is very possible to losely couple the V (so for example you can have different implementations for different devices).
--ZhuLien (talk) 1:46, 21 October 2013 (UTC) — Preceding unsigned comment added by 27.32.141.11 (talk)
MVC Diagram
I believe the arrow from "User" to "View" in the MVC diagram is reversed. — Preceding unsigned comment added by MarsBay (talk • contribs) 21:50, 23 March 2016 (UTC)
- The arrow is fine because it shows the direction of information flow. The verb is wrong. 50.185.134.48 (talk) 06:00, 2 April 2016 (UTC)