|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. Please supply full citations when adding information, and consider tagging or removing unciteable 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.
|WikiProject Computer science||(Rated Start-class, Mid-importance)|
Confusing and Wrong
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.
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. 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.
Three tiers, three layers and MVC
What about following associations?
- Presentation layer = View
- Business layer (application logic) = Controller
- Data layer = Model
Batch processing and MVC
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
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.
- 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. 184.108.40.206 (talk) 02:31, 19 November 2016 (UTC)