Talk:MVC
From APIDesign
Contents |
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. If you get to the Trygve Reenskaug web site there are links to several articles including the original unpublished Xerox report on Thing-MVC as well as his report on being at Xerox and the work on Smalltalk-80.
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.
Here is some clarification on the above. Some distinguished members of the Smalltalk-80 development team did not accept the MVC concept neither 30 years ago nor can accept and live with it now (after multiple existing frameworks try to implement it with different level of adherance).
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.
Whenever we are to deal with software, we prefer software that has friendlier user interface (not necessarily, the fancier one, but the one that meats our expectations and intuitive - in short, WISIWIG). This user interface has two parts: those who develop it and those who use it. The second part is the majority of software users. Nowadays it is not necessary to be software engineer or programmer to use software. Recall comercials from Microsoft (I know it is not the right place to mention this company, but..) where a 5-year girl is taking shots and using PC to process them. Children are using computers for playing games without knowing how thise applications are written and implemented, and they should not know that.
So, we have two groups of people: software professionals who are to create software for end users and the end users. The first group would be happy to avoid the painstaking process of developing guis (if they can). That explains the large number of available frameworks. The problem with those frameworks (including GUI Builders) is that the result is the program skeleton. In most cases you still need to program event listeners after you get the program from the framework. The beauty of Naked Objects (I appreciate the work done by Richard Pawson and Dan Haywood) is that there is no need to spend hours programming guis. User interface is provided for free (if you accept the standard user interface look provided by Naked Objects). I would like also to mention that Naked Objects could not emerge as the concept and the framework earlier than Java/JVM (and later, C#/CLR) offer the reflection mechanism to get inside the objects.
The idea of avoiding programming user interfaces was developed and popularized about the same time MVC was conceived. The only problem was the language barier - it was developed in Russia and from 1979 to 1991 there were 30 publications and presentations at various conferences on this. I think that Jaroslav probably can still read in Russian and he may check the bibliography (Dialogue-82 and 84, for example).
What I am trying to point out is that there are areas of software development where there is no need to spend time on user interface programming. It does not mean that this can be universal and cover all possible domains. By no means, it cannot. But we need to look at this opportunity in the same way as it exists in different domains. We do not develop web browsers for each new web application. We use the existing ones (and there are only few of them). One application is different from another in the content of the HTML pages that are displayed by the browser. That is, user interface is represented by data which is interpreted by the browser. I think this can be extended further.
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.
Unnamed wrote:
Just to clarify, I am not against Swing or AWT, but against proclaiming any of them (as well as SWT) as the follower of the MVC pattern. You may not know that even in Smalltalk-80 (yes, where MVC was first implemented) they actually moved from the original implementation of the MVC and what we have since then in most of the frameworks is not true MVC just because these implementations do not separate the three pieces of MVC, but in most of the cases have V and C together.
User:JaroslavTulach: Right, that is a sign of MVP.
Besides, most of those who claim to be gurus in design patterns consider MVC as only the means of developing GUIs while MVC basically reflect the way we actually communicate with each other and process any information ourselves. That may be the reason why the original idea of MVC was never published and only 15 years later MVC was used by GOF for illustrating several simple patterns. If you check the way GOF and later authors suggested to describe design patterns and document them, you would see that they follow (without real understanding or, better to say, intuitively) the same MVC pattern. I think that even before OO was introduced as the way of doing software many of software developers used it, but without calling it as MVC. Similar approaches were used in non-OO environments before OO languages became dominant in software. We can go thru this and it may be the subject for a book. I have tons of examples of MVC outside of software domain. So, if interested we can continue to work on this. The slides from Geertjan you mentioned in your previous posting represent the 'traditional' vision or view on MVC and they follow Sun's blueprint which represents Sun's official approach and how they think MVC is implemented in Java.
Naked Objects and Trygve Reenskaug
Per the mentions above to Reenskaug, and also Naked Objects, here's what Reenskaug says in the foreword to Richard Pawson's thesis (for which Reenskaug was the external examiner):
"If the original MVC had been published at the time, Naked Objects would now appear as an important extension and implementation of its ideas. As it is, the original MVC was not published at the time and Richard Pawson’s Naked Objects appear as an important and independent contribution."
As for how Naked Objects implements MVC, the model is clear: that's the pojos. The view is clear too: that's the auto-generated OO UI. As for the controller, the way I think about it is that it is encapsulated in the metamodel which Naked Objects builds up and which describes the interaction protocol to the model. In terms of the layered architecture, Naked Objects really autogenerates both the presentation layer *and* the application layer.
--DanHaywood, author: "Domain Driven Design using Naked Objects"
Here is the quote from the same preface to Richard Pawson's thesis: 'The original version of MVC was never published. In my naïveté, I believed that everybody wanted to empower their users so that MVC was merely an obvious solution to a common problem.'
As to the importance and the originality of the Naked Objects, I would like to mention the reaction on its first presentation in the US in 2002 - the review by Larry Constandine which is used from time time by those who barely familiar with the concept of the Naked Objects. The reaction showed that there was a concern that Naked Objects can significantly decrease the army of software developers who are involved with building user interfaces and programming guis. Besides, it may also decrease the need in training services of those who teach how to do guis.
As to the question asked at the heading of this blog, I would not bet on Swing as a framework. It is definitely not a framework in any sence. There was an attempt to create such by Sun (the announcemnt was made over two years ago), but it looks like this project was canceled. So, we are to stick with GUI Builders and other frameworks and program GUIs which is a very unpleasant exercise. I do not want to sound as an idealist, but there is no need for the ideal definition of MVC. The only what I would like to point out that you can find MVC in such products like relational databases and report generating tools, for example. Relational databases are usually opposed to OO software while report generators are usually OO. If you look at the relational database from the MVC standpoint the model is represented by the tables and their relationships (keys). The databases have or use views for extracting / presenting data from the tables based on the queries you provide. The controller part of the database is its engine which binds queries and processes them. For report generators, report templates or forms can be considered the views. By the way, you do not need to program such forms - they can be generated and stored (using some database or specially formatted files). You can have multiple forms for getting / producing different reports from the same data - definitely, they are views. You can extend the number of examples. Maybe, it is worth to mention that the idea of using plug-ins (the concept, not the details of specific contracts for a particular product) is basically MVC - the model here is the table that is used by the engine to decide which plug-in to use in which circumstances, and so on. The same idea was used before plug-ins were (re-)invented. 40+ years ago software engineers used techniques similar to plug-ins for switching processing based on some value. By the way, this reminds me that such construct like 'switch/case' in Java and other languages follows the same concept. If you analyze any of the existing and documented design patterns, you will find out that they also follow the MVC concept (maybe, implicitly) - they all have a template which is used for generating the skeleton of the implementation; they have a view which is used for inputting some information that results in different output generated by some engine (controller). My major point is that MVC is not just for efficient user interface design. Until next time, David
cootassonge said ...
I am doing my best and interest from new readers can only encourage me. Thanks for sharing your note.
--JaroslavTulach 23:22, 14 July 2011 (UTC)
Zsombor said ...
Sorry, but I cannot urakntdee to troubleshoot every problem that readers might encounter, particularly when travelling (I'm out of the UK until early November). What I have managed to establish is that the message you're seeing is caused by the Zend_Service_ReCaptcha component throwing an exception. It indicates that the contents of the challenge field are not being received by the verify() method. There are several possible causes: you have mixed up the GET and POST methods, there's a misspelling in the first argument passed to the verify() method, or there's something in your setup that's preventing the ReCaptcha values from being displayed/transmitted. Whatever the cause, I'm fairly confident that it's not an error in the book or in the code on the CD. The files on the CD were thoroughly tested before the disk was created.I suggest that you conduct some troubleshooting steps of your own, such as looking at the source code generated by the form with the ReCaptcha widget in it, and examining the contents of the $_POST array with print_r(). Let me know if you manage to locate the cause of the problem. I'm curious as to why the challenge value should not be sent when the form is submitted.
--Zsombor 13:39, 23 October 2013 (CEST)
Alex said ...
This is not classical MVC, according to the Martin Fowler Controller does not have direct link with view.
--Alex 08:24, 16 March 2017 (CET)
Follow
Pretty nice post. I just stumbled upon your weblog and wanted to say that I've truly enjoyed surfing around your blog posts. After all I will be subscribing to your rss feed and I hope you write again very soon!
--cootassonge 19:30, 13 July 2011 (CEST)