When I've implemented MVC:
* I have one controller for each view
* Each view knows about it's controller, but only as a generic
controller (either as an interface or a base class)
* Each View registers it's controller as the event listener for each of
it's buttons.
* Each controller translates a "generic call" in itself into a specific
call to the model that may or may not cause a state change.
* In response to state changes, the model notifies all views.
* The notification can include the state change information, OR
* The view can request the state change information from the model.
* The view changes updates what is presented to the user as needed
based on the change in state.
The reason to implement the listener in the controller is to separate the
implementation of the business logic from the display logic. This makes the
implementation of the specific function on the model independent of the generic
function on the view.
Example: an application has several views that each have a "next" and
"previous" button. Each view registers the next button with its controllers
next function. Each controller provides next and previous functions that invoke
one or more methods on the model that may cause a state change.
This provides a decoupling of the business logic from the display logic. If I
want to change what is displayed, or how it is displayed, I change the view. If
I want to change the response to user input, I change the controller.
An example of why this is nice: I've got a clock face that I want to use as a
stop watch (elapsed time) and as a timer (count-down timer). View could be
identical, and just change the controller to change the functionality. Start,
Stop and Reset would all have different meanings that are handled by the
controller. I know that a bug in the timer code is independent of the stop
watch code.
In certain situations, it may be beneficial to implement a view as another
instance of the MVC pattern. An example of this would be where a user is making
choices in a configuration, and those choices don't get saved into the
application state until the "OK" or "Apply" button is clicked. While the
choices are being made, the views internal state is stored in the views model,
and when OK is clicked the choices get stored into the application's model.
Whether or not it's worthwhile to implement a view as another internal MVC
pattern depends upon the complexity of the view vs. the added complexity of the
overall system. IMHO, the choice should be to go with what makes the overall
system the easiest to support.
Jim
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
