Talk:MVC
From APIDesign
| Line 1: | Line 1: | ||
| - | + | ==== David wrote: ==== | |
| - | + | ||
| - | You may want to review the | + | You may want to review the [[wikipedia::Naked_objects|Naked Objects]] project as well to see whether [[MVC]] is obsolete or not. |
| - | What you may not realize is the fact that MVC cannot be ignored or abandoned even if you wish this to happen. | + | |
| - | MVC is the fundamental concept that drives basically every our action, not just those that are related to software guis. It was suggested as the means of creating the multi-windowed user interface for Smalltalk-80 30 years ago, but it does not mean that it was not used in software implicitly (without calling the names) before. It may be surprising for you, but look at the concept of a library. It is exactly MVC in action - you supply arguments necessary for a routine or a method (in OO terms) to work with - that is what is called the View in MVC, you provide the name of the method (Model), and finally you call it - that would be the Controller which produces some results that drive the changes in your 'View' and define the next action of your software. | + | [[User:JaroslavTulach]]: I am looking at it right now. So far it seems like a nice way to avoid necessity of writing [[GUI]] by using [[Convention over Configuration]] techniques to generate it automatically. I like that (actually in beginning of [[NetBeans]] we used [[JavaBean]]s as POJOs and generated [[GUI]] automatically; until we found that property sheet is not the nicest [[GUI]] under the [[Sun]]). But I still fail to see where is the [[MVC]]! View is auto-generated. Controller is said to be merged to the ''behaviourally-rich'' object itself. How can you (as person who complains that [[MVP]] does not separate controller and view enough) see [[MVC]] ideas in such merger? |
| - | You may not aware of the fact that what was actually implemented in Smalltalk-80 was not what was provided by the MVC inventor for it. Based on some relatively recent postings of Trygve Reenskaug (the real inventor of MVC), the version that made to Smalltalk-80 was rewritten from his original code after he left Xerox and | + | |
| - | There is another thing I would like to mention. Members (some) of the original Smalltalk-80 development team do not accept MVC even after 30 years of its existence. But you cannot ignore the fact that it exists with or without your acceptance and will continue to exist. The matter is how consistent your implementation and how close it to the concept. The closer it is the better. Otherwise, using such framework and its output (code) becomes more and more complex and | + | What you may not realize is the fact that [[MVC]] cannot be ignored or abandoned even if you wish this to happen. |
| - | And as you mentioned MVP is much more painful to work with than with true MVC. As I indicated above, just have a look at | + | [[MVC]] is the fundamental concept that drives basically every our action, not just those that are related to software guis. It was suggested as the means of creating the multi-windowed user interface for Smalltalk-80 30 years ago, but it does not mean that it was not used in software implicitly (without calling the names) before. |
| + | |||
| + | [[User:JaroslavTulach]]: OK. | ||
| + | |||
| + | It may be surprising for you, but look at the concept of a library. It is exactly [[MVC]] in action - you supply arguments necessary for a routine or a method (in OO terms) to work with - that is what is called the View in [[MVC]], you provide the name of the method (Model), and finally you call it - that would be the Controller which produces some results that drive the changes in your 'View' and define the next action of your software. | ||
| + | |||
| + | [[User:JaroslavTulach]]: I have to admit my imagination cannot envision [[MVC]] when thinking about routines. I bet I am not the only one. | ||
| + | |||
| + | You may not aware of the fact that what was actually implemented in Smalltalk-80 was not what was provided by the [[MVC]] inventor for it. Based on some relatively recent postings of Trygve Reenskaug (the real inventor of [[MVC]]), the version that made to Smalltalk-80 was rewritten from his original code after he left Xerox and different from the original intent. The version from Smalltalk and later articles (that did not appear until 1987 and there was no documentation in Smalltalk) simply shifted the concept to what is currently called [[MVP]]. | ||
| + | |||
| + | [[User:JaroslavTulach]]: Can you point us to more info via some links? Thanks. | ||
| + | |||
| + | Because of that later implementations of the respective supporting software (MFC, AWT/Swing, just name the few) as well as 'GUI Builders' are supporting basically [[MVP]]. | ||
| + | |||
| + | [[User:JaroslavTulach]]: That is my understanding as well. | ||
| + | |||
| + | Even with the statement that [[MVC]] is implemented by such and such framework, it does not mean that the framework actually does what it states. Simply, if you try to say something different people would not buy it. | ||
| + | |||
| + | [[User:JaroslavTulach]]: I think people often use [[MVC]] as a metapattern name. In this meaning the [[MVC]] is an idea (in the way Plato's philosophy is using it). Its actual realizations as either [[MVC]] (via HTTP) or [[MVP]] (via [[GUI]]) or [[DCI]] (if you claim it is just another implementation of the old [[MVC]] idea) are then closer or further from the absolutely clear and sharp ideal [[MVC]]. | ||
| + | |||
| + | There is another thing I would like to mention. Members (some) of the original Smalltalk-80 development team do not accept [[MVC]] even after 30 years of its existence. | ||
| + | |||
| + | [[User:JaroslavTulach]]: I do not understand meaning of this sentence. Can you explain what you mean? | ||
| + | |||
| + | But you cannot ignore the fact that it exists with or without your acceptance and will continue to exist. The matter is how consistent your implementation and how close it to the concept. The closer it is the better. Otherwise, using such framework and its output (code) becomes more and more complex and painful. | ||
| + | |||
| + | |||
| + | |||
| + | And as you mentioned [[MVP]] is much more painful to work with than with true [[MVC]]. As I indicated above, just have a look at [[wikipedia::Naked_objects|Naked Objects]]. You do not need to program any [[GUI]] listeners and that is the beauty of the approach. You concentrate on your business logic. You do not need to spend long hours on adjusting the look and the layout of your user interface. | ||
| + | |||
| + | |||
| + | |||
| + | I think that if you could avoid programming user interface for [[NetBeans]], for example, but just use one framework that would do all visualization and passing input to the IDE model, the development cycle would be much shorter and more efficient. You would not need to spend time on fixing user interfaces. | ||
| + | |||
| + | [[User:JaroslavTulach]]: [[NetBeans]] were (and still are) auto-generating the interface on top of [[JavaBean]] abstractions and it has own drawbacks. These days it is quite hard to find property sheet or property panel in the product. People rather design the [[GUI]] manually to guarantee proper focus behaviour, navigation, perfect layout, etc. | ||
| + | |||
Until the next time, | Until the next time, | ||
David | David | ||
| + | |||
| + | [[User:JaroslavTulach]]: Thanks for your comments. Feel free to update the page with additional info. | ||
| + | |||
| + | |||
| + | ==== Side notes ==== | ||
| + | |||
| + | Sorry, but it is difficult to judge whether the referered article is good or not just because not everybody can read in Czech. | ||
| + | Besides, the statement that DCI obsoleted MVC seems incorrect. It is simply one of the recent attempts to consistently implement the [[MVC]] paradigm. | ||
| + | |||
| + | [[User:JaroslavTulach]]: OK and yes, the page is in Czech. Which is also the reason why I translated its part to English. | ||
Revision as of 09:41, 10 November 2009
David wrote:
You may want to review the Naked Objects project as well to see whether MVC is obsolete or not.
User:JaroslavTulach: I am looking at it right now. So far it seems like a nice way to avoid necessity of writing GUI by using Convention over Configuration techniques to generate it automatically. I like that (actually in beginning of NetBeans we used JavaBeans as POJOs and generated GUI automatically; until we found that property sheet is not the nicest GUI under the Sun). But I still fail to see where is the MVC! View is auto-generated. Controller is said to be merged to the behaviourally-rich object itself. How can you (as person who complains that MVP does not separate controller and view enough) see MVC ideas in such merger?
What you may not realize is the fact that MVC cannot be ignored or abandoned even if you wish this to happen. MVC is the fundamental concept that drives basically every our action, not just those that are related to software guis. It was suggested as the means of creating the multi-windowed user interface for Smalltalk-80 30 years ago, but it does not mean that it was not used in software implicitly (without calling the names) before.
User:JaroslavTulach: OK.
It may be surprising for you, but look at the concept of a library. It is exactly MVC in action - you supply arguments necessary for a routine or a method (in OO terms) to work with - that is what is called the View in MVC, you provide the name of the method (Model), and finally you call it - that would be the Controller which produces some results that drive the changes in your 'View' and define the next action of your software.
User:JaroslavTulach: I have to admit my imagination cannot envision MVC when thinking about routines. I bet I am not the only one.
You may not aware of the fact that what was actually implemented in Smalltalk-80 was not what was provided by the MVC inventor for it. Based on some relatively recent postings of Trygve Reenskaug (the real inventor of MVC), the version that made to Smalltalk-80 was rewritten from his original code after he left Xerox and different from the original intent. The version from Smalltalk and later articles (that did not appear until 1987 and there was no documentation in Smalltalk) simply shifted the concept to what is currently called MVP.
User:JaroslavTulach: Can you point us to more info via some links? Thanks.
Because of that later implementations of the respective supporting software (MFC, AWT/Swing, just name the few) as well as 'GUI Builders' are supporting basically MVP.
User:JaroslavTulach: That is my understanding as well.
Even with the statement that MVC is implemented by such and such framework, it does not mean that the framework actually does what it states. Simply, if you try to say something different people would not buy it.
User:JaroslavTulach: I think people often use MVC as a metapattern name. In this meaning the MVC is an idea (in the way Plato's philosophy is using it). Its actual realizations as either MVC (via HTTP) or MVP (via GUI) or DCI (if you claim it is just another implementation of the old MVC idea) are then closer or further from the absolutely clear and sharp ideal MVC.
There is another thing I would like to mention. Members (some) of the original Smalltalk-80 development team do not accept MVC even after 30 years of its existence.
User:JaroslavTulach: I do not understand meaning of this sentence. Can you explain what you mean?
But you cannot ignore the fact that it exists with or without your acceptance and will continue to exist. The matter is how consistent your implementation and how close it to the concept. The closer it is the better. Otherwise, using such framework and its output (code) becomes more and more complex and painful.
And as you mentioned MVP is much more painful to work with than with true MVC. As I indicated above, just have a look at Naked Objects. You do not need to program any GUI listeners and that is the beauty of the approach. You concentrate on your business logic. You do not need to spend long hours on adjusting the look and the layout of your user interface.
I think that if you could avoid programming user interface for NetBeans, for example, but just use one framework that would do all visualization and passing input to the IDE model, the development cycle would be much shorter and more efficient. You would not need to spend time on fixing user interfaces.
User:JaroslavTulach: NetBeans were (and still are) auto-generating the interface on top of JavaBean abstractions and it has own drawbacks. These days it is quite hard to find property sheet or property panel in the product. People rather design the GUI manually to guarantee proper focus behaviour, navigation, perfect layout, etc.
Until the next time, David
User:JaroslavTulach: Thanks for your comments. Feel free to update the page with additional info.
Side notes
Sorry, but it is difficult to judge whether the referered article is good or not just because not everybody can read in Czech. Besides, the statement that DCI obsoleted MVC seems incorrect. It is simply one of the recent attempts to consistently implement the MVC paradigm.
User:JaroslavTulach: OK and yes, the page is in Czech. Which is also the reason why I translated its part to English.
Follow
