Talk:MVC
From APIDesign
| Line 6: | Line 6: | ||
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 differnt 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. 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. 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 ro say something different people would not buy it. | 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 differnt 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. 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. 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 ro say something different people would not buy it. | ||
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 painfull. | 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 painfull. | ||
| + | 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 beaty 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 interfce for NetBeans, for example, but just use one framework that would do all visualization and passing input to the IDE model, the devepoment cycle would be much shorter and more efficient. You would not need to spend time on fixinf user interfaces. | ||
Until the next time, | Until the next time, | ||
David | David | ||
Revision as of 14:28, 8 November 2009
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. You may want to review the '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. 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 differnt 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. 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. 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 ro say something different people would not buy it. 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 painfull. 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 beaty 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 interfce for NetBeans, for example, but just use one framework that would do all visualization and passing input to the IDE model, the devepoment cycle would be much shorter and more efficient. You would not need to spend time on fixinf user interfaces. Until the next time, David
Follow
