This page presents a very abstract way of seeing ModelViewController. I was inspired to really document this here when reading the postings in ModelModelViewController and WhatsaControllerAnyway

I am working in a project which uses a model driven development approach similar to MDA. So our UML model is a kind of 'platform independent', and a generator converts it into Java code (EnterpriseJavaBeans on serverside, Swing on clientside).

The basic pattern in our UML model is MVC based, means:  Classes deriving from 'Model' are the persistent entities of the business and result in EntityBeans, classes deriving from 'Controller' result in SessionBeans and have a state machine resulting from the corresponding State-Diagram. Classes deriving from 'View' are generated into a Swing form and represent the client part in the J2EE c/s scenario.

Ok so far, but when regarding a client/server cut, the data contained in the 'Model' must be transported to the client and vice versa. For that we generate transport objects.

When now looking at the client side framework part, it was obvious that there is a MVC pattern too:  The 'Model' is built by the transport objects containing the data. The 'View' is our Swing-Form (a JInternalFrame with its components). The 'Controller' ... well, is a class we introduced later and called it a 'Presenter' to distinguish it from the 'big Controller' in talk. It's job is to maintain the server connection, handle GUI events perhaps transforming them into server calls.

Well, I said we use Swing. This framework indeed has it's own MVC view, so our Swing experts use the term 'Model' and 'Controller' when talking about the functionality of a JTable or JComboBox.

So one can see that you can break down the sight (or abstraction level ?) onto this system and you will find a MVC pattern at every level, which inspired me to think of it as a FractalModelViewController pattern. It is somewhat like zooming into an image.

The question now is, is this MVC paradigm then applicable for other parts of the software too?

Why, you see that I change the subject from 'pattern' to 'paradigm', as that's what it is now. No more a real pattern, but a way to look at the just existing components:

Looking at the 'Controller' of the most abstract model, the TransportObjects may be seen as its 'View', the EntityBeans as its 'Model'.

Looking at the 'Model', yes, the EntityBeans can be seen as a 'View' of the data in the database, whereas the tables represent the 'Model' at this level. The controller would be the access layer, e.g. the DBC interface or the DB engine itself. (I know that this makes the database an inherent part of this global MVC system, which may be unusual).


A remarkable point is, that in this approach the 'View' of one tier becomes the 'Model' of the next:

* EntityBean      = View in coarse grained 'Model' and Model in coarse grained 'Controller'.
* TransportObject = View in coarse grained 'Controller' and Model in coarse grained 'View'.


(Just to complete this abstraction: Think of a class which maintains its data in attributes of different types and presents them to the outer world in a string (e.g. by calling 'toString()' in Java). Imagine too, that this class has a simple form of 'state' ... ok, this may be too far away ...).

-- DirkDetering

----

Related: the idea that web (e.g., web services) works as a FractalModelViewController pattern was also considered in the article, "Fractal Model-View-Controller as the web" ( http://icite.net/blog/200308/fractal_mvc.html) in August 2003. 

----