This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I just wanted to know your opinion about this MVC Design :
The Controller gets a reference to the Model which is retrieved from the Server before GUI - startup.
It also gets a Reference to the View and starts the GUI after initialization.
The View gets a Reference to the Controller to call methods like "book room" or "search rooms", and a reference to the model to get the initial data.
Upon startup it registers an Observer at the Model to be informed of changes.
The Controller takes the requests from the model, calls the Server and performs changes on the model.
The only reason (as I see it) to call the View is to show messages (error ...).
You planning to use the observer design pattern - whenever the model changes the view also get updated automatically?
In general your approach looks fine. Yet the GUI really is the JTable with each record a Room (a model per se). So your controller needs to call "book" and "search" functions interacting with the table model and the data file/server.
For error notifications, it depends on how many exceptions you are catching in the client code. The server side surely has many to cater so classifying or grouping exceptions into 1 or 2 is a good idea. I used 1 server exception (remote exception) and 1 database exception (record not found type exceptions).
I have some database exceptions, which are caught in my business service and then an appropriate business exception is thrown instead (so a RecordNotFoundException is caught and a NoRoomFoundException is thrown for example). And I have a lot of business exceptions, because not everything is a RemoteException or a NoRoomFoundException (for example RoomAlreadyBookedException).
In my GuiController all these business exceptions are caught and a GuiControllerException is thrown (with an appropriate message for the user) and so in my application I only have to catch this GuiControllerException and show its message.
Ok, throwing exceptions and showing them in the GUI is also a good idea. In my approach it would lead to the Controller not knowing anything about the GUI ...
I have to think about it.
I changed my approach to the following:
GUI gets the Model and it into a JTableModel. this JTableModel class serves as a Wrapper or Adapter for the Model and filters out columns like "deleted" and enhances data for better readability.
The GUI calls the Controller to book or search and the Controller contains the business code querying the Server.
The Controller updates the Model and the Model offers an updateModelListener Interface for the GUI which therefore updates itself.