Your opinion on MVC please.

[Filip Moens]

I 'm troubled regarding the best/cleanest/correct MVC design to use.
The literature is far from being single-minded about how to proceed.
The "classic" design shows a reference from a View to its Controller, from the Controller to its Model and from the Model to its Views.
So, the controller does NOT know about the Views it controls.
Let's take an example.
The application is running in client mode (connected to a server) and the user wants to connect to a different server.
Initially, the button push is handled in an actionPerformed in the View.
Now, an input pop-up is needed to get the new server details.
I would create and show this pop-up (a JDialog) from the View code.
Why?
The controller does not know about the Views it controls.
Moreover, Views need not be Swing applications.
So, the Controller has no idea what kind of pop-up to show, and there is no reference from the Controller to the View.
The data filled in by the user is passed to a method call in the Controller, which attempts to connect to the new server.
If all goes well, the new Model is passed back to the View (returned from the method, not by calling a method on the View).
If things go wrong, an error needs to be displayed. Again, since the Controller has no idea what kind of View it is controlling, I throw some DataAccessException in the Controller method code. The View catches it and shows an appropriate error message.
What do you boys and girls think about this?
What confuses me is that I've seen statements about:
- the View not handling errors.
- The controller acting as a Listener (presumably ActionListener) for the View(s)). This implicitly means that the Controller shows the input pop-up, and possibly the error pop-ups.
Moreover, strictly speaking (pure MVC, or what is mostly considered to be) the Model should not be returned to the View from a method call on the Controller, but the Controller should update the Model and the Model calls an update on its Views.
Please comment.

[Philippe Maquet]

Hi Filip,
Interesting thread. I feel myself still a bit unconfortable with the MVC pattern, so I cannot be of much help here. Much of what you wrote looks reasonable to me, so I am looking forward seeing comments on it from people like Andrew and Jim.
Best,
Phil.

[Bill Robertson]

I have mentioned this in other posts that no matter who
the expert is you are going to get different interpretations.
I found a very clean method at
MVC Example.
Whether the Controller hands back data back to the view is a non
stop argument. But yes, most people say the view should have
no inner class listeners, perform no exception handling, and
display no error messages. This can be a task, but possible.
In regards to sending back a DataAccessException to your view, well
what happens if the exception is the object has already been booked
by another user, or the object cannot be found because it has been deleted,
do you not want to inform the user of these things. Think about if
the user goes to book something, you come back with a very generic error
message, and then refresh the screen and the user sees it is booked (but
with a different value from a different user) this could confuse the hell out of a user unless they were told it was booked by another user.
Just a thought.

[Philippe Maquet]

Hi Filip and Bill,

Bill:
no matter who the expert is you are going to get different interpretations.

That's probably why MVC still confuses me more than other design patterns, even complex ones. Each time I think "OK, now I got it !" (including a few variants), it happens that I read some more other way to "apply MVC".
If you look at this very good example posted on March 11, 2003 07:29 AM by Eugene Kononov in this thread, you'll see a big difference with the example referenced by Bill above (which looks very good too BTW) : the View is listening for changes in its Model, updating itself accordingly, instead of being updated by the Controller.
There are other possible differences :

In both examples above, the view doesn't know its controller : ActionListeners are controller call-backs registred by the controller on the view. OK, very understandable. But the description of MVC in Max's book is a bit different : "The view calls the controller and instructs", and indeed in Max's examples there are direct calls, no callbacks.

In the same thread as above, Eugene explains that the model is the good place for business methods (like find() and book()). But I've read elsewhere that the right place for such business methods is ... the Controller, which in turn will update the model. BTW, thats what Max does in his book.

There are so many variants of MVC !
In comparison with other well-known patterns, MVC is ambiguous. If I tell you : this in a Singleton or a Multiton or a Factory or an AbstractFactory ... I don't need to tell you much more for you to guess what I am doing. While telling you "I use MVC" lets many details in the shade.
Best,
Phil.

[Bill Robertson]

I am enrolled in Harvard's Master of Software Engineering program
and in one of our classes we went over the MVC pattern. My teacher
quickly pointed out that trying to understand how the relationships should work is fruitless. But according to my notes he mentioned a few things
that may be of interest:
1. Try to keep the lines of communication unilateral, not bi-directional.
In other words the controller calls the view and the view calls the
controller is bi-directional.
2. The less each part knows about eachother the better. Whether the controller knows about the view and the model, but the model and view
know nothing about eachother, OR the view knows about the controller
and the controller knows nothing about the view but the controller knows
about the model yet the model and the view know nothing about eachother.
3. Out of the three parts, take a stab at which one is most likely to
be replaced. Lets say in this case the View (which is most often the
situation) if any of the two parts comunicate with it, do so via an
interface. And ideally make this component unaware of the other two.
The other two simply calls methods on the view (in this example) via the interface but the view never goes outside itself and calls the controller nor the model.
hope I did not confuse the matter.

[Filip Moens]

Hi Bill and Philippe.
Bill, I had a look at the example you referred to.
Sorry to say that I am not convinced that this is the way to proceed. It is "too simple" to convince me.
One of the situations where MVC is appropriate is when there are multiple views possible for the same model.
I am fully aware that this is not a must, but I don't see this situation handled in the example you referred to.
Let 's assume we modified the Controller code so that it keeps track of all Views it controls.
Now, the Controller gets a bookRecord call from somewhere.
In the example you provided, this is triggered by a push on a button.
Which button? From which View?
Let's further assume we can determine the originating View.
Now, the Controller must get back to the calling view to ask for the input data.
The Controller does not know what kind of View called it.
One view may display a pop-up to input data, another may enable some JTextFields, ComboBoxes, whatever.
The user inputs the data and the Controller can continue.
In this situation, the View is not an ActionListener, but pretty much behaves as one.
I think it is simpler that the original action that triggered all this is first handled in the View itself (getting the input data) and passing these data to the Controller.
Now concerning error messages (or information messages for that matter), the same problem occurs: one View may want to display an error pop-up, another View may want to display a message in the status bar.
This could be handled by calling a method showErrorMessage (or showInfoMessage) on the originating View from the Controller.
Now what if you have two Views displaying the same data, and an attempt is made to modify a record that was deleted in the meantime.
We display an error, the model is updated and then? Would you call an UpdateViews from the Controller instead of from the Model as is seen in most descriptions of the MVC pattern? And the link from the Controller to the Views opposite to what you see most of the time when MVC is used.
I fully agree with you that the lines of communication should be unilateral as much as possible.
Bill, regarding the Exceptions thrown back to the View, I use 2 types of Exception to indicate different error situations.
Whatever goes wrong in the Controller, the Model is always updated (well, if necessary) from the Controller and the message put in the Exception is not generic but contains the message that the View needs to display (being for example "Server not found", "Record deleted", "Record already booked", ...").
And Philippe, join the club, I'm struggling too with this pattern.
Over the years, it has come up several times, and no matter what I did, I was never really happy about the way it was done (either by myself or by someone else).
This is a pattern which is always explained by a very simple example.
Alas, these simple situations hardly ever happen in the real world.
I 'll keep you posted if I ever find a solution that suits my "unhappiness".

[Bill Robertson]

I agree with everything you said about the example I gave. The example was basically a way to point out that there are so so so so many ways to implement MVC. I have links to many MVC designs and it was the first one on the list and I knew it was easy so I picked it.
My final conclusion has come to what I have learned from my professor
and that each situation may call upon different relationships.

One of the situations where MVC is appropriate is when there are multiple views possible for the same model.
I am fully aware that this is not a must, but I don't see this situation handled in the example you referred to.

Agreed its not handled by this example because the author is basing his design on the CURRENT situation. And For this project you don't have mutiple views.

Now what if you have two Views displaying the same data, and an attempt is made to modify a record that was deleted in the meantime.
We display an error, the model is updated and then? Would you call an UpdateViews from the Controller instead of from the Model as is seen in most descriptions of the MVC pattern? And the link from the Controller to the Views opposite to what you see most of the time when MVC is used.

You could call an update based upon who knows the view, more likely the model. But this is not set in stone. But I would not call the update
from the model for the sake of what most people do. If your controller
knows the view but the model doesn't, update from the controller.
In this case the view calls the method on the controller
we display the error and the controller returns back a new model reflecting
the deletions.

Bill, regarding the Exceptions thrown back to the View, I use 2 types of Exception to indicate different error situations.
Whatever goes wrong in the Controller, the Model is always updated (well, if necessary) from the Controller and the message put in the Exception is not generic but contains the message that the View needs to display (being for example "Server not found", "Record deleted", "Record already booked", ...").

Nice.
But like I said before, a lot of people say no message handling in the
view, its just a dumb gui. But as I have also said before I believe
its the situation at hand.
Definitely keep me posted on the results of you hunt for the perfect MVC
design. If you need to even create a new post message, something like
"The Holy Grail of MVC"

[Filip Moens]

Thanks for your comments Bill.
I'll keep thinking about it.
It 's just that I want a solution that finally makes me happy.
I'll keep you posted on my hunt for "The Holy Grail of MVC".

[John Smith]

One of the situations where MVC is appropriate is when there are multiple views possible for the same model.
Yes, that's the intent, and you are right, the example that you are referring to misses completely on how MVC can resolve the communications between the model and the multiple views.
Let 's assume we modified the Controller code so that it keeps track of all Views it controls. Now, the Controller gets a bookRecord call from somewhere. In the example you provided, this is triggered by a push on a button. Which button? From which View?
OK, here is how it typically works. The views that are interested in a particular model subsribe themselves as the listeneres to that model, normally by implementing a listener interface. The model mainains a list of subscribers (views), and when the state of the model changes, the model broadcasts the changes to all listeners. For example:

    public void fireModelChanged() {
        int size = listeners.size();
        for (int i = 0; i < size; i++) {
            ((FlightsModelListener)listeners.get(i)).modelChanged();
        }
    }

In the "dumb" version of the model, it broadcasts all the changes to all the views, indiscriminantly, and it is up to the views to interpret the changes when the notification is received. In the "smart" version of the model, it has some itelligence to know which views are interested in which particular changes, so the model may send notifications selectively. The advantage of the former model is that when you add a view, the model doesn't need to change. The advantage of the latter model is that you reduce the (presumably) expensive notifications. In either version of the model, it doesn't know which particular button (or any other visual control) triggered the event, and this is precisely the intent of MVC, -- no matter how many GUI elements you add or change in your views, the model should not change, -- it simply doesn't know anything about the contents or functionality of the views.
How does the user action results in the change in the model? Well, that's the job of a controller. The controller listens for user actions (such as clicking the button), and maps these actions into calls to the model. Again, the idea is that when you add or change the view, the model doesn't need to change.
I think it is simpler that the original action that triggered all this is first handled in the View itself (getting the input data) and passing these data to the Controller.
Yes, that's one approach. But here is the disadvantage, -- your view is now acting as a controller, taking the responsibility to determine which pieces of data are needed to act on a user action. That is, your view is now smarter than it could be, and this may contaminate your MVC. The alternative is to let the view be as dumb as possible, -- all it should know is how to render the data in its widgets. When the user motions the intent, the controller takes over, requests the additional data items from the view if neccessary (by calling the public methods of the View), and invokes the appropriate method of the Model.

Now concerning error messages (or information messages for that matter), the same problem occurs: one View may want to display an error pop-up, another View may want to display a message in the status bar.
This could be handled by calling a method showErrorMessage (or showInfoMessage) on the originating View from the Controller.
Again, we have a problem. Who should have the knowledge of what contstitutes an error? If it is a violation of some business rule, it would be logical to think that it should be contained in the Model. When the Model detects an error, it may broadcast the notification to the views, which will display it to the user. However, if we are talking about exceptions that are thrown from the model, the controller is probably a better candidate to catch these errors and to select the views where the error should be displayed.
And Philippe, join the club, I'm struggling too with this pattern.
Over the years, it has come up several times, and no matter what I did, I was never really happy about the way it was done (either by myself or by someone else).
I struggled with MVC myself, until I realized that the intent of MVC is exactly the same as any other pattern, -- to break the comlexity into several loosely coupled pieces, each piece having a nnarrow and well defined set of responsibilities. Granted, MVC is a bit more complex than other patterns (one reason is that MVC itself is a combination of several patterns), but again, the idea is the same.
Perhaps the most important thing is not to try to be "compliant" with any particular version of MVC, but instead to be consistent with the motivation of MVC. If your code is easy to read, extend, and maintain, no one will give a damn if it is a real MVC or not, -- everyone will be happy, including you, your fellow programmers who work with your code, and definitely your grader, too.
[ November 15, 2003: Message edited by: Eugene Kononov ]

[Bill Robertson]

Perhaps the most important thing is not to try to be "compliant" with any particular version of MVC, but instead to be consistent with the motivation of MVC. If your code is easy to read, extend, and maintain, no one will give a damn if it is a real MVC or not, -- everyone will be happy, including you, your fellow programmers who work with your code, and definitely your grader, too.

I could not agree more!!!