Talk:MVC

From APIDesign

Revision as of 00:31, 12 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. 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.

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.

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.

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.

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"

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