Recursive Model View Controller
Recursive Model View Controllersee HierarchicalModelViewController
ModelViewController looks great when you first see it. I have, however, not met anyone who doesn't struggle with it when applied in a nontrivial program. The following might help:
Problem
Using ModelViewController in large (what is "large"?) applications leads to a number of problems, including the problems of
Apply ModelViewController recursively. What is a model for some entities of the system might be a view/controller to other parts of the system.
Example
For example, you want to have a data entry form in a dialog window. For the "data subsystem" (the model) of your application core the whole dialog window plays the view/controller role. This model and view/controller are connected via a communication mechanism to exchange the necessary information (e.g. getDataSet, setDataSet, change notifications).
The dialog window itself is, however, also structured according to ModelViewController. Its visual representation and interaction elements are views/controllers (widgets, window frame etc.) that communicate with a model, the dialog window. The dialog window as a model and the views/controllers (widgets) communicate in terms of e.g. setSomeValue/getSomeValue, setAnotherValue/getAnotherValue and change notifications etc.
The dialog window assembles this information "pieces" into data suitable for using in the getDataSet/setDataSet communication with the data subsystem. When this communication actually happens is, however, subject to the logic in the dialog window (e.g. user presses an APPLY button).
The dialog window also provides a good place for format conversion. ModelViewController assumes, that the data in the model (used to do calculations etc.) is in the format of what one would actually display on the screen. However, what to do when the data you have is of type integer, but you widget demands that all that it can display is a string? In the dialog window one can now "moderate" when such "impedance mismatches" occur.
The dialog window acts as a view/controller with respect to the data subsystem, while it acts as a model with respect to the visual representation and interaction elements of the window on the screen.
The data subsystem is the model for the dialog window, but maybe its also (a set of) view(s)/controller(s) for the application core. Then, however, it is arguable if such a construct should still be called ModelViewController.
Recently it happened to me that I applied the structure, but in another context. I had to prepare a java object for display. Unfortunately, it was supposed to be used by different View/Controller's from Swing (JTable, JTree, and some less complex ones). I sneaked adapters in, which played View/Controller for the actual object, and models for the widgets. See AdaptDontImplement.
See ModelViewControllerAsAnAggregateDesignPattern.
You are not making ModelViewController recursive, you are just making the Observer pattern recursive. In other words, your model is an observer on the real data. VisualWorks (arguably the definition of ModelViewController) uses Observer recursively like this, and in fact the original Smalltalk browser used Browser as a model, but Browser was really a "view" of the classes. It was in fact *not* an observer, and this led to bugs where a change to one browser would not immediately show up in another browser. I fixed this bug by changing the browser so that it was an observer of a global object representing system changes.
The reason why people struggle with ModelViewController is that it is complicated. I find it easier to teach if you teach each of its component patterns separately, and then combine them in ModelViewController.
Hmmm, if my understanding of patterns is correct, the name of a pattern (or an aggregation of patterns) is an important property of a pattern (aggregation). (Didn't you write something like this in DesignPatterns?) So yes, maybe RecursiveModelViewController might not be a good term.
From a practical point of view, I see it, however, a little bit different. I don't care so much if it is correct to claim that I make ModelViewController recursive or if I apply the Observer pattern recursively. I am more interested in getting a working and clearly structured software. And the above described approach helps me to achieve this.
In general I don't find ModelViewController complicated, but just limited and not well scaling to (my) real-world problems. Also, I see people repeating mistakes (at least in my limited view) again and again with ModelViewController.
Maybe one of the worst examples of this are the InterViews and Fresco frameworks from MarkLinton (JohnVlissides and tons of other people also involved, you know that better than I do). The frameworks are excellent research results, OO driven to the max, well thought out and consequently build, but IMHO with a slight problem.
When I first had to use InterViews nearly ten years ago, I was shocked by the communication overhead involved in the system (in InterViews the sheer volume of objects which need to be created is overwhelming). Everything on the screen was a separate object. InterViews objects just had a fare to fine grained granularity.
Then they started Fresco, and repeated the same mistake: Every nitty-gritty thing on the screen was an object, everything was a variant of ModelViewController (they called it SubjectView?), every small text field, every slider needed access to a "subject". All this communication had to be set up. There was no abstraction level in these frameworks (at least I didn't see on) which was suitable for a larger application.
I don't want to take care of hundreds of models, views and controllers when "designing" and building a larger application. I want to be able to think in terms of preference dialog windows, data entry forms, file chooses, etc. I want to think about the application's conceptual interaction model, the principles for information representation in the application, about the general interaction and control mechanisms in end-user terms, etc. And RecursiveModelViewController helps me out here:
I can think and specify in my (or application specific) terms, size the models (which you deny that they are models) so that it makes sense for the tasks to perform. I can structure the application according to the problem domain. When it comes closer to some implementation I can deal on another level with gluing hundreds of tiny views/controllers to some "models" - not affecting my principle structure/concept of the application. The tiny ModelViewController combinations are then non-intrusive to my application design. RecursiveModelViewController provides me with another "language" to talk about my application than the ModelViewController granularity of the GUI toolkit/framework which I am supposed to use. This helps me and maybe it would help others, so I presented my idea here.
I have this pattern. It has helped me to think of MVC in large and small scales. -- GregVaughn
The innovations of InterViews and Fresco were (for the most part) aimed at structured vector graphic applications with DirectManipulation, and patterns like TooledComposite. Although they led the way in breaking the one-to-one relationship between server-side window objects and on-screen widgets, there are many other ways to do this (like TclTk) that do not require such extensive object-oriented programming for essentially a textual or forms-based application. I've worked quite a bit with both the widget glyphs of InterViews, and the graphics of the UnidrawFramework, and I can take or leave the widget stuff, but there is nothing like Unidraw for constructing custom graphical editor applications (ok, HotDraw is like it). --ScottJohnston
This is not to refute your comments, but rather to 'vote' on an approach. ModelViewController is definitely hard to get a good handle on. So far, for me, I find it easier to think of ModelViewControllerAsAnAggregateDesignPattern and to think of applying Observer 'recursively' and in different contexts.
Now I may think differently down the road and YMMV. Any other opinions or preferences? --KielHodges
I had seen this page some days before but hadn't quite convinced myself to read it. I was just trying to make working with MVC easier and involve less code. Trying to do this, I got something which in my opinion reflected RecursiveModelViewController, because Controller contains many other small controls, and View contain many sub-views. Anyway Models are always independent.
So often, I see any pattern that involves behaviour just being another way to describe 'Real Time Data Flow diagrams' In fact, when I implement an object, I design it's internals with that kind of thinking. The methods to an object then just become accessors/mutators, etc.
But I'm pretty sure that I still have a lot to learn about OOP. I did see one comment in this or a related page on this site which said that objects were meant to abstract BEHAVIOR, not data. That seems intuitive, but not easy to be a puritan about implementing. Think of ORMs (object relational modeling), at least. They're really popular now.
--Dennis Gearon
EditText of this page
(last edited May 17, 2010)
or FindPage with title or text search