From: ddet@... (Det)
Date: 2002-09-17T18:33:10+09:00
Subject: Re: MVC and OO Design?

Friedrich Dominicus <frido@q-software-solutions.com> wrote in message news:<87hegq5wes.fsf@fbigm.here>...
> This is correct the Modell notifies the Controller or the other way
> round the Controller queries the modell for needed input 

Hum, there are some different views of what a controller
is or how the M, V and C should look like. They are much
influenced by the GUI-framework one uses or the overall
architecture which should be built.
Therefore MVC is in modern reading not named a 'pattern'
any more but a 'paradigm' (and everytime causes a lot of
discussion in developer teams).

As with the classical view IMHO there is a triangle 
between M,V and C. So the Modell notifies the *View*, not
the Controller.
The Controller does not query the Model per Design.
(This is only a hidden technical aspect, if necessary to
do his job).

> forwards it
> to the Model get back the values from the Model and than 
> updates the View. 

The Controller does not update the View in the above
mentioned scenario. The View (displaying part of a GUI)
updates itself (ok, based on push or pull ...).
The Controller updates the Model caused by events 
coming from the GUI-Controls (User).

In some frameworks (Java too) there is a tight coupling
between Controller and View, as the Controllers are
*Action*Controllers, listening to GUI-Events sent by
GUI-Components directly. So a GUI-Component is a
displaying (View-)Component and an event trigger
for controllers at the same time.
But by that way resizing a window, leaving a text field 
or saving a dataset (Model) is not really different.

If you write a standalone GUI-only Application this 
can be a meaningful way to make things work.

But there is a more general view too, e.g. used in
distributed environments. There the Model is an object
net used for persistence purposes and is indeed queried
by the Controller. The Controller rather reacts on more 
coarse grained Business Events than on single mouse clicks
and is mentioned to implement Business Processes. This can
also be the start of a subcontroller with a specific View
(a GUI-Frame, Window or similar).

Instead of reacting to Business *Events* the Controller 
can also be implemented to provide Business Services
called by clients, no matter if they are GUIs, scripting
engines, 3rd party products using an API-Library ...
The Controller then is the only connection between View
and Model, as it provides the Model query for the View
too.

So thinking in terms of MVC the whole application can
appear like a hologram (or a fractal picture) showing
a general MVC structure where parts of it build a 
MVC structure again. 
(coarse grained: Model as persistent object net,
Controller as service provider classes, View as all
kind of clients.
fine grained look into the Model:
classes in the memory as View, tables in the
database as Model, the mapper functionality of either
a tool or a RDBMS, or whatever as Controller.
fine grained look into the GUI: 
GUI components as View, event listener as Controller,
client-side representation classes as Model).


Bye
Det