Talk:Model-view-controller

From Wikipedia, the free encyclopedia

Shouldn't it be called model-controller-view?

Contents

[edit] Origins of MVC

Many of the changes I am making are to make the article more in line with the concepts back in the 1987 Smalltalk paper. Specifically...

  • The controller is the event processing mechanism. You don't just write event handlers in the View that just immediately call the controller. The controller exists, at least in spirit, with the event handlers.
  • Views and controllers are tightly coupled for a reason. If you have two different views with different buttons, text boxes, etc., they cannot share the same controller. Why? Because they don't have the same events.
  • The model is not just a dumb data storage object. This is where all your business rules live. If you are using the controller to process business rules, than you are not following the pattern correctly. Rather, you are writing in the VB's (crappy) "everything in the form" pattern.
    • You had me until this one. Just because an application relies on MVC does not mean that everything must be shoe-horned into MVC. In order to acheive the level of decoupling that ultimately is the promise of MVC, the model can indeed be "just dumb data", or at least an ephemeral collection of values (values which might be objects upon which method calls can be made -- therefore not "just dumb data"), probably retrieved from a fine-grained service layer, albeit via a coarse-grained "facade" interface (business delegate), that the controller references. Jemptymethod 10:32, 20 August 2007 (UTC)
  • In order to understand the MVC pattern, people need to see how it applies to real frameworks. While you may argue that some technologies (e.g. WinForms) doesn't support the true MVC pattern, it is important that people see it and understand how it differs.

Things that are needed...

  • Each component needs more than just a bullet point. We should use the Xerox and Smalltalk documents to give a more indepth description of each.
  • The openning needs to clearly state that the MVC pattern was specifically designed for graphical user interfaces.
  • We need an entire section on how web applications differ from the GUI applications that MVC was originally designed for. Specifically the bit about how it has two triads, one on the server and one on the browser.


-J. Allen


Re tight coupling: I'd argue that controllers and views are orthogonal rather than tightly coupled. The logic of a domain manipulation is quite different to that of the view. What is to be displayed anyway? A simple boolean success/fail message? A 12 page debugging report? Which bits of data from which bits of the object graph are to be collected for viewing? Are you observing object state or messages passed between objects or both? How is all this data being interpreted into a meaningful human-readable display? This is all view logic which doesn't really belong in a controller layer. The same UI interaction can result in different views - say verbose or shortened versions of a report or different content dependng on admin / ordinary user privileges. Views and controllers can have different rates of change but tight coupling means they are not free to vary independently. Actually tight coupling means they don't exist at all in any meaningful sense. V & C have been merged and instead of MVC you simply have presentation & domain layers.

- Noel Darlow

"Actually tight coupling means they don't exist at all in any meaningful sense. "

You may disagree with it, but that is the one and only definition of MVC as presented in the smalltalk paper. You are free to criticise MVC by pointing that out, but to change its definition is wrong. Grauenwolf 17:19, 29 October 2006 (UTC)

I'm not sure if I am changing the definition or if we are required to use the original smalltalk definition. Concepts often evolve and improve over time - and it's been a while. In my defence I would cite Martin Fowler in Patterns of Enterprise Architecture who makes the comment that many original smalltalk implementations did not in fact separate V and C. Also, from his web page about gui architectures: "I've lost count of the times I've seen something described as MVC which turned out to be nothing like it".

Noel Darlow

I am pretty sure that the MVC concept is of much wider use than for creating user interfaces. From my personal experience (1978-1991), it can be and was used for creating easily extandable software systems (not just one application as most of the frameworks mentioned suggest). If necessary, the respective references can be provided.

David Rozenberg

I believe that Trygve Reenskaug did not publish his original work just because he understood that the MVC concept is much wider and natural to us (human beings). I would serously question any declarations that started in some blogs that there is no need for this pattern or concept. I also think that the interpretation of it made by some people involved with Smalltalk-80 did not add any good, but confused many software developers.

David Rozenberg —Preceding unsigned comment added by 71.224.122.75 (talk) 16:39, 31 December 2007 (UTC)

[edit] Platform Independence

here I'd just like to outline my view of' MVC' with regards to the platform-independance/C++ etc stuff in the article.

My view is that both the Model and Controller are written in a platform-independant language. The Model is tied to the View through a very loose notifier/listener (or 'observer') mechanism. So the Model knows to a certain extent that a View exists, but only very loosely. The Controller however has even less knowledge of a View, and simply implements an interface that allows the model to be changed according to the application logic. So the controller might implement a "Load File" method which the View calls when the user selects "File->Load"... or something along those lines.

So when porting to a new OS, only the View code is rewritten, along with the code to call the appropriate methods on the Controller and to respond to updates from the Model.

Does anybody else have any views on this?

MVC does not make a program language independent. MVC is just a way to model an application, a set of rules how program parts should interact. MVC is language independent in the sense that you can create a MVC application in C++, in Java or Cocoa. But a MVC program written in Java is not easier to port to C++ than another program. The reusable aspect of MVC leis therein that the parts act indepently - parts call each other with messages, they do not have to know each other by name or specific method - and can be replaced or extended.
One single program is too small to take advantage of reusability of MVC. The real benefit comes from a MVC framework, that a single program can use and extend.
I agree with the above comment that the platform independence benefits of MVC are largely imagined, or at least unsubstantiated. In my experience, models are typically tied very closely to a document/persistence framework which impedes reusability in the same way that close ties from a GUI framework impedes reusability of an application's view classes.
Expanding on my earlier comments: MVC does not give you platform independence, but can help make code easier to port from one platform to another. This is particularly true when GUI APIs are the most tightly-coupled of the platform-dependent APIs used by an application. In this case all (?) of the the GUI API calls are confined to a set of view/controller classes. But the point is that you are still dependent on the underlying GUI API.
As currently stated, the benefits of MVC are conflated with the benefits of using a cross-platform language. I think language issues are irrelevant here. It is possible to obtain benefit from MVC using a platform-dependent language. Similarly, using a cross-platform language with MVC does not automatically grant platform-indpendence. For example, an application written in python to the Cocoa bindings (using PyObjC for example) is still platform-dependent even though it is written in cross-platform language. Hence I propose removing the language issues from this discussion.
I have specific disagreements with the current content. For one: "Since the model and controller generally have no knowledge of the view, the programmer is free to implement both in a cross-platform language such as C or C++." The implication here seems to be that view classes necessarily require a language that is not cross-platform. Which is frankly wrong; as noted above, the language is irrelevant here. Platform dependence can arise through the use of platform-specific APIs, not just from choice of language.
Also the statement that "Theoretically, an application written entirely under the Cocoa framework for Macintosh could easily be ported to Windows under the .NET framework, as long as the model/controller is written only in C++." is incorrect. For starters, Cocoa is Objective C, which to my knowledge is not supported under .NET. Secondly, Cocoa explicitly incorporates Model and Controller APIs, which means that the application is coupled to the underlying API in more than just the view classes.
So I agree that there are some benefits to using MVC in cross-platform development, but the current description of these benefits is not accurate. --AlastairR 4 July 2005 01:22 (UTC)


About the Advantages/Disadvantages section: The disadvantages are a bit unclear to me. The second paragraph gives a disadvantage, but it's more a generic disadvantage (don't freeze the ui too soon), and it's resolved by the MVC, as explained as the advantage: A flexible view for a static model. There's also the (not MVC-specific) problem that they're programming without understanding the model. No architecture is going to save you in that area, and it's not a MVC-specific problem.

[edit] Patterns

I read on another WIKI that the Model-View-Controller is made from three patterns: Composite, Observer and Strategy. Does anyone know if this is correct? - Daniel Lewis

I think it's fair to say that these patterns are useful in creating an MVC architecture, but are not required. In other words it is possible to build an MVC-compliant architecture without using these patterns. --AlastairR 4 July 2005 01:22 (UTC)
I disagree with AlastairR. As stated in the Gang of Four's "Design Patterns - Elements of Reusable Object-Oriented Software" (the bible for design patterns), the main relationships in MVC are given by the Observer, Composite, and Strategy design patterns. 213.93.217.159 14:59, 14 July 2007 (UTC)

I would say that MVC is decomposable into just two patterns: Observer and Strategy: the View is an Observer on the Model and the Controller is a Strategy for the View. --gschadow 19 Dec 2005

MVC predates the GoF design patterns, so it may be more accurate to say that the Observer and Strategy are based on the MVC design pattern. - J. Allen 20 July 2006

[edit] Image

The image http://upload.wikimedia.org/wikipedia/en/1/15/Mvc.gif is not exactly correct, the model doesnt not really update the view, it just publishes the events, the view or the controller takes care of actually updating the view (because its subscribed to the evenmodel of the model) . With the current text associated with the model image one could assume that the model has knowledge of the views, which it has not. Thats why there is such a high level of decoupling.

I'd go further and say that the controller also cannot update the view. What I mean is that the controller may issue an instruction telling the view to update itself but should not pass a model to a view. The view gets its own data: that's what MVC is all about ie finessing the standard presentation/domain separation with a further split in the presentation layer between controller and view.

Shouldn't we therefore say that the point about the Controller is that it can be exchanged. For example, the same view could display the data of an object using a Controller that responds to very few events, but it could be used as an editor using a conroller that converts keystroke events into changes to the model. --gschadow 19 Dec 2005

I've edited the page recently and either I messed up my submission or it's been edited. If there has been some editorial intervention can you mention it here: I don't want to appear to be spamming.

All this talk about "the model must not update the view" or "the controller must not pass the model to the view" is utter rubbish. The MVC design pattern merely identifies the responsibilities of each of the three modules, it does not specify how they are to be implemented, or how each module communicates with another, or how changes in the model make their way to the view. These are all implementation issues, and as such are not cast in stone but are entirely fluid, limited only by the skill of the programmer and the language beng used.

Provided that the implementation contains three distinct modules, each with the relevant responsibilities, then it is MVC, period. The fact that someone else's implementation may be different from yours does not make your implementation right and the other implementation wrong. They may be different, but they are both right.

Tony Marston 10:50, 19 June 2006 (UTC)

The key point about MVC is that view and controller are separate layers. If the controller were to pass model data to the view you would have to edit the controller every time you change the set of data displayed in view. Quite clearly the controller and view would not be separate and therefore it's not MVC.

Actually both the Controller and the View should have a reference to the model.

The View uses its reference to the model to extract data that is needs to display. The Controller uses its reference to the model to initiate updates based on the events it is processing.

In the Smalltalk implementation, the View is actually in charge of creating a pointer to the controller, telling the controller to point back to it, and registering itself with the model.

In some implentations, the controller actually updates the View using the Model. In others, the View automatically updates itself. An example of the latter is bound controls in ASP.Net. The controller calls the DataBind command on the view, which in turn updates itself using the model.

The only requirement is that the model doesn't know about the view or controller. It may expose generic event hooks, but that's about it. Otherwise the model cannot be used in other MVC triads.


-- J. Allen 20 July 2006

[edit] 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've 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.


[edit] True MVC vs. "crippled" MVC on/for the Web

The article is not clear enough about interactions between M, V and C. Their functions are also described somewhat insufficiently. This is probably common for any recent description of the pattern and has resulted in claims that traditional web applications (completely) implement (full) MVC. They can't. For that they would require Server push.

Rich Internet Application and AJAX are changing this picture slightly (the requirement still stands, but if unavailable there are compromises).

--Aleksandar Šušnjar 21:03, 18 January 2006 (UTC)

The MVC doesnt require server push. The application of the Observer pattern to allow the model to send notifcations to a view is a common and elegant enhancement to the MVC. It is not a core part of the core MVC pattern.
You are talking about an active model as described in the Smalltalk-80 description. Yes, this would require server push for a web application which is not possible (but may badly be simulated with for instance an AJAX timer on the client side polling for state change on the server). However, passive models are possible in web applications. 81.235.236.122 (talk) 17:09, 24 March 2008 (UTC)

---

Actually messages from the Model to the View are part of the original Smalltalk MVC design. The idea was that multiple MVC triads could share the same instance of a model object. When the model is updated by any triad, it sends a "changed:" message to all views registered with it. Note that with this design the model has no concept of a "View" aside from the fact that it listens to events the model sends.

Sounds like the observer pattern to me.

- J. Allen 20, July 2006

---

The article really needs a kind of clarification. Separation of Model and View is not sufficient for a library or Framework to implement MVC. Every library or framework for interactive applications presents (View) data (Model) to the user and handles user interactions (Controller), but that does not mean that every such library or framework implements MVC.

For instance: "In the case of WinForms, the View and Controller are compiled into the same class.", means that WinForms are not MVC implementation (view and controller are not separated). And next: "The duties of the controller are split between three places."(!)... only justifies this view (the controller is not centralized). The same applies to MFC and many other listings.

The need for another kind of clarification is rather tricky. A part, that is by itself MVC does not automatically make the whole MVC. Here is the example: XForms document is Model (instance document in the head section) - View (layout in the body section) - Controller (DOM Event model). But that does not mean, that any web application which uses XForms as View implements MVC. Such clarification is needed to avoid misconceptions like Model (Frame level) and Model (Control level) in Swing section.

The article should focus more on MVC itself, its parts, their responsibilities, and their relationship. The list of libraries (frameworks) which does (not) implement MVC is unnecessary and confusing.

--Maroš Ivančo 16:40, 10 February 2007 (UTC)

[edit] MVC graphic

The MVC graphic used on the page is confusing. I think it should have the dashed lines removed (the observer paradigm has its own page) and the direction of the arrows should be explained. -- cmh 04:55, 13 May 2006 (UTC)

It also uses transparency which breaks where alpha channels are not available (such as printing).

[edit] 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.

[edit] List of Frameworks

I'd like to suggest that the list of frameworks is not good content for this article, and that it would be more appropriate to link only to those frameworks which already merit their own article on Wikipedia. For the rest, a pointer to an external listing of software might be better. Szarka 15:02, 16 May 2006 (UTC)

Also, some of these aren't even MVC. I'm from a php background and, in this language at least, MVC is very poorly understood. People seem to get the presentation/domain split reasonably well but stop there. That's not MVC though. MVC goes further, breaking the presentation layer down into separate View & Controller layers.

Removed the paragraph about some PHP frameworks not being MVC -- better to remove the non-MVC ones from the list than to write a bad paragraph about it.

I agree on szarka´s note´s, today while i surfed the internet on freshmeat.net there was a new software project announced smutty [1] maybe someone of the moderators can add that to the article


--I think it is important to note how, or even if, the msjor frameworks support MVC. How is especially importent to me because the original MVC pattern was specific to a SmallTalk GUI toolkit. From what I've read, you literally could not violate the MVC pattern.

As for "separate View & Controller layers", that is not entirely correct. In the original MVC pattern they were implmented as seperate objects, but they were very tightly coupled. Each controller worked with one and only one view. Grauenwolf 17:15, 29 October 2006 (UTC)

[edit] View vs Controller in web applications

The part in bold does not make sense to me as this is invoking change by calling on the model. When the data is gathered it is outputted into HTML which is then rendered by the browser. Would this not be considered the job of the controller?

"View: Renders the model into a form suitable for interaction, typically a user interface element. MVC is often seen in web applications, where the view is the HTML page and the code which gathers dynamic data for the page. "

"Controller: Responds to events, typically user actions, and invokes changes on the model and perhaps the view."

Wikvin 18:25, 13 July 2006 (UTC)

Views are read-only. They would not manipulate model state. As you say, that's the job of the controller.

-Noel Darlow

I think this is a huge area of confusion for many people. I would suggest including some specific comparisons between m/v/c, as Noel did in his response, which was very helpful. the current comparison/definition section is confusing, especially with the high repitition of 'domain' without much explanation. it makes me think that 'domain' is some buzzword i should know about if I am truly understanding the article. I am scared to edit the page myself, but I hope this reaction helps! -red daly (atgmail.com if need be)

The long list of frameworks for web applications poses the question - Why do we need that many of them? Don't they provide the help for constructing the same type of the application? How they are different? What are the advantages of using one framework comparing to others? Which one is the champion?

David Rozenberg

David Rozenberg question is what made me read this far. With any framework, "the devil's in the details" which is something you don't find out without significant study AND experience. It takes so long to plumb the depths of the frameworks available that no-one can learn the details of them all. If anyone knows where to find people who want to discuss these differences knowledgeably and politely without getting zealous about any one solution, let me know. --GlenPeterson 17:27, 8 November 2007 (UTC)

[edit] AVC, the Application View Controller an alternative to MVC

Recently (Jan 2007), I developed a python module that makes the job of MVC in a fully automatic and transparent way. The connections between the controlled variables and the widgets are autogenerated by looking for matching names between widget names and variable names.

The application is completely unaware of the presence of the connected variables, it reads and writes them as normal variables. Only if the application requires to be immediately notified when a connected variable changes value, a notify handler must be added to the application.

For more info see the AVC home page [2].

Fabrizio Pollastri --Pollastri 09:09, 2 February 2007 (UTC)

[edit] Regarding .Net

ASP.NET does not strictly require a model. The developer has the option to create a model class, but may choose to forget it and have the event handlers in the controller perform any calculations and data persistence. That said, using a model to encapsulate business rules and database access is both possible and preferable.

To me this sounds inaccurate. First no language enforces the use of models, MVC frameworks usually do, therefore comparing .Net Runtimes versus Ruby on Rails seems like comparing Apples to oranges. Secondly .Net does support a model, it's called DataSets. To create custom models you create a Typed Dataset. It's actually done very well in .Net and is fully persisted and serializable.

If nobody has a compelling reason against this, then I will correct this section. —The preceding unsigned comment was added by Kibbled bits (talk • contribs).


I don't understand the implementation emphasis in the .net entries. MVC is a *logical* solution to a problem which the developer has to decide is correct or not. The implementation in various language can be demonstrated given an example, but to expect a platform to enforce design consideration on the developer is wishful. Harecourt 20:58, 8 May 2007 (UTC)

[edit] Can anyone make model part of the pattern description more understandable?

I can't! But I can tell you why it is hard to understand ... maybe that will help someone re-write it.

It says that the model layer shouldn't be confused with the domain layer, but doesn't explain what the domain layer is. It would be helpful if someone could tell us what the domain layer is (I have had a look but can't find anything on it). The next sentence talks about domain logic, saying that domain logic adds meaning to raw data, and then gives an example OK, but given that it is domain logic, and the domain layer shouldn't be confused with the model, is this something that the model should or shouldn't do? I would guess not. But to me it sounds like something the model should do, otherwise why give an example in this section? Confused? I am!

OK - hope that helps someone make this section less confusing. I would love to have a rock steady definition, in a topic where understanding the boundaries for these three terms is crucial + very hard. :-) Michaelmcandrew 23:24, 9 July 2007 (UTC)


I agree the pattern description needs rewriting to make it more understandable. It also needs to explain how the Observer, Composite and Strategic Patterns are incorporated in the MVC-pattern. (As stated in the Gang of Four's "Design Patterns - Elements of Reusable Object-Oriented Software").
A nice real world example can be found here http://csis.pace.edu/~bergin/mvc/mvcgui.html 213.93.217.159 16:12, 14 July 2007 (UTC)

-- It is very confusing. The model is the domain layer (the term comes from "domain model"). Some people seem to think of data access is part of the model too but everyone will agree that this is where domain logic happens. —Preceding unsigned comment added by 212.159.44.241 (talk) 18:10, August 30, 2007 (UTC)

[edit] Perl MVC -- Maypole? Catalyst needs editing.

Howdy. I'm not an expert on whether Maypole is a popular enough distribution to include in the list of Perl MVC suites, but am enough of an advocate to think that the languge needs as wide an array of distribution options as other languages in the list (PHP, Python and even -Ruby- have multiples).

Additionally, what's written there for Catalyst is mighty Advert. I would hope at the least the package mentions would point to CPAN for reference. As an example: The difference between DBIx::Class and Class::DBI is not immediately apparent even to those familiar with the language (or at least myself) and reference would clarify.Ogre lawless 07:47, 25 July 2007 (UTC)

[edit] MVC and MVP?

How is this different than MVP? Why isn't there an article on MVP (Model View Presenter) on Wikipedia? 129.120.86.169 22:48, 23 October 2007 (UTC)

[edit] MVC2

The DragonPHP uses MVC2, but what is that? They just link (back) to wikipedia (to this article). And regarding PHP I don't think that there's a need for versioning. AFAIK, Java has MVC1 and MVC2 due to the JSP and Servlet difference. PAStheLoD (talk) 21:22, 14 February 2008 (UTC)

[edit] Maybe this article should just admit ...

The article (and much of this talk) follows the Smalltalk idea of MVC, notably that the View is read-only and the Controller accepts the user inputs. There is a newer pattern, where the View handles both input and output and the Controller primarily exists to connect View and Model. One very clear image and description of that idea is at [Apple's Objective-C tutorial]. There are some spots in the main page citing MVC use of systems that follow the newer pattern (e.g., Swing and EE), yet describing them as if they follow the Smalltalk definition, which they do not.

I'm not attempting to argue the relative merits of the two models, here, but this disjunction has become so large, yet so unacknowledged, in the industry as a whole that I think maybe the Wikipedia article really ought to describe both (or at least, to admit to their dual existence). Jackrepenning (talk) 17:56, 10 March 2008 (UTC)

[edit] Joomla as a MVC application

I recently added Joomla version 1.5 to the list under PHP, but the change was undone by Yarzar110. So before I readded it I wanted to discuss it. From what I have messed with the source of Joomla 1.5 it follows the model discribed in the article. Can somebody confirm or deny this? MarkRomero (talk) 23:14, 26 April 2008 (UTC)

It might be, that Joomla is a MVC application. But so are thousands of applications. What is listed here, are MVC libraries/frameworks you can build with. However Joomla probably contains such a library as a fundamental component. From my point of view the interesting question is, if you could use that component independent of the whole joomla product and how this component is called in special. --79.196.208.123 (talk) 11:21, 27 April 2008 (UTC)

The reason why I added it was because phpXCore was on the list and its description is a content management framework. As far as I know the library could be used independently, but since it is relatively new there have not been any derivative works based on the library. MarkRomero (talk) 13:50, 27 April 2008 (UTC)