passed 151/155!!!

[John Rushington]

Debra,
Thanks for all of the help; I have learned a lot about MVC by reading the discussion.
First, I would like to ask you if, as one reader remarked, MVC should really be called MMMVMC, instead of MVC. Now, it seems to me that there would only be one model, though there could be an arbitrary amount of controllers and views. In fact, the MVC diagram you show has only "state change" and "state query" arrows pointed at the model: there is no "change model" command; furthermore, it makes sense to me that all application data (the model), would only exist in one place, and that different views would represent this data in different ways, which might include leaving out or including certain aspects of (the same) model. What do you think?
Secondly, I would like to point out that you repeatedly refer to the object that contains the Views (that have registered with the model), or the Controllers (that have registered with the View), as being of type ArrayList (java.util package). Although this is probably a good implementation of the necessary functionality, the object that stores the Views or Controllers does not have to be implemented this way, in fact, it is generally better to leave the actual class as an implementation detail, and refer to the actual class used through an interface, such as List, or Collection. This way (if you used the List interface), you could later change the implementation to a LinkedList, etc. very easily. Using an interface to reference the implementing class also allows you to use the java.util.Iterator interface to generically iterate over the implementing class.
[ July 17, 2002: Message edited by: John Rushington ]

[Debra Bellmaine]

Hugo and John,
Hugo, I'm glad that my discussion was helpful...good luck to you!
John, I actually think that the number of Models, Controllers, and Views are totally architectural issues. I can think of situations where you might have "sub-Models", each representing a data object, in a large system. And so you would end up with multiple models. I would never put all the code for Customer maintenance in the same Model as Order Entry data, for example. I think the main thing is to get the idea of the separation of church and state: the Model resides on a server (ususally) and represents the data object. The View resides on the client, and represents the user's view of the data - for that specific application. And the Controller makes sure that both are communicating in a correct fashion, but allows them to be de-coupled. Lots of ways to slice and dice when the concepts are understood.
With regard to my references to ListArry, I agree it would be better to simple refer to List or Collection, as there are lots of ways to implement. Good luck to you also on your project!
All the best,
Debra

[Nate Johnson]

Greate score! I am looking forward to the day when I finish my essay exam.
I have one question for you. Do you know of any links that talk about sun's mvc pattern that you learned in their class?
Thanks!
[ July 19, 2002: Message edited by: Nate Johnson ]

[Debra Bellmaine]

Nate,
I actually don't know of any specific links to any Sun sites that discuss MVC. You could try doing a search at their site...they do post lots of white papers, etc. The instructor-led classes are pretty expensive, but they also offer web-based courses that are much more reasonable. I'm doing one right now to study for the Web Component Developer exam.
Debra

[Nate Johnson]

Originally posted by Debra Bellmaine:

These were the major design decisions:
Implemented RMI for the network connection.
Implemented the MVC pattern for the overall architecture of FBN.
I had a LockManager class.
I modified the Data class.
I had a custom Table Model for my JTable.
Thanks again to you guys,
Debra Bellmaine
SCJD2

So did you have any sort of facade that would do the big work, like booking a flight or search for a flight, so the client would be eaiser to implement for a junior programmer?

[Sam Stackly]

Hi Debra,
Just followed connection factory thread and was looking on your comment about connection factory.
is it true that all your clients will talk to one instance of remote connectionFactory? or for each client you have one instance of connection factory?
Thanks again for your help
Sam

[Nate Johnson]

One more question, Debra. Can you mention where you handled your error handling for booking a flight? When a fireBookFlight was called from your view, did the view do the error handling to be sure there were enough available seats? Or did your controller get notified that a bookFlight needed to be performed and it took care of the checking and notifying the view if errors occured?