Brief discussion about MVC

Basicly a controller object is needed to control the flow of a use-case (for complex use-cases multiple controller objects might be needed). If the user needs to interact with the system the controller object shows the relevant view object(s). Information from the model can be presented at the view, information from the view can be used to perform operations on the model or both can happen. Either way we need some protocol for the way the controller object(s) communicates with the view object(s).

In a simple application we'll mostly need the user to enter information and then start an operation (typically by clicking the "Ok" button). The information could be text typed by the user, selections from list(s), a choice from alernatives and so on. The operation could be one that changes the state of the model, reads information from the model (i.e. searching) and so on.

Of course the user should also be able to reject the operation (typically by clicking the "Cancel" button or by closing a window or dialog box).

When either of these user actions (ok or cancel) happens a controller object should be informed.

The simple way to do that is to let the view object call a method in the controller object - this implies that the view must know (have a reference to) its controller.

A big question is whether the information from the view object should be passed to the controller object as parameters or whether the controller object should require the information by calling methods in the view object - typically get-methods.

The first alternative is typically more simple, but gives a stronger coupling from the view object to the controller object.

The second alternative normally means more code in both objects, but it will typically be rather simple (get-methods in view and call to these methods from the controller). One advantage is that the view can be made more flexible and independent of the controller object.