MVC and my design

[Oliver Rensen]

Hello ranchers,

I am a newbie here and this is my first post. I'm working on URLyBird Version 1.1.3 and have some questions, but I will post every question in a separate thread. I'm not sure about my MVC-Design, and I plan to implement it as following: My view is the GUI-class. The controller consists of a separate class which contains the event-handling for the GUI-components, and the main-method resides in this controller, too. View and controller are contents of my thin client. When the URLyBird-application is launching, at first the controller will be instantiated. Then the view will build the GUI, and the view connects to the controller through hook-methods. So far so good, but my problem is: Where is the model? I think in the real world the model should be the Data-class which reads and writes the records, and the model must know the views to notify them when the database has changed. But IMO this is not a requirement for the URLyBird-assignment and therefore it would be out of scope. Especially for the SCJD-project I will prefer the table-model from the JTable as my MVC-model rather than the Data-class. When a user books a record in the view, the controller will be notified. After that, the controller sends the booking-information to the server. Because I implement a "thin client", the server does some plausibility-checks like the 48-hours-rule or whether the record is already booked or not. When the booking is done, my program goes back from the server to the controller, and the controller tells the table-model, that the data has changed (the JTable-column "customer holding this record" must be filled, because the record is booked). The table-model (which is the MVC-model) knows his view and updates the JTable. For every client who starts the URLyBird-application, there would be only one view, one controller and one model. And now my question: Is this design a valid implementation of the MVC-paradigma?

Many thanks in advance.

Regards

Oliver

[Andrew Monkhouse]

Hi Oliver,

Welcome to JavaRanch and this forum.

One of the major reasons for having the MVC pattern is to allow each element to have one responsibility for each element. The view is designed to display the information to the end user. The controller is designed to get the commands from the view and forward them to the appropriate module. The model is designed to abstract how you get and set data in the back end system (database).

At the moment you have your controller sending information directly to the Data class and/or server. This means that there is no abstraction layer here - your controller must be aware of how it can connect and what the correct protocol is to send data.

This works at present because you only have one class sending / receiving data - your controller class. But it is not very reusable if you decided to extend your application at all. If, for example, you needed to add an extra view, what then: do you add a new controller for this (in which case you are duplicating your connectivity code), or do you have the one controller for both views (quickly becoming overly large and unwieldly). What if your next view is a JSP - how do you reuse any of your database connectivity code?

If you create a separate model, most of the problems go away:

        [View] -----\
           |         > [Model] --//-- [Database]
     [Controller] --/

Now we have a common way of connecting to the database no matter what type of view and/or controllers we have. And if we want to add new views and controllers, then their logic can be separated from the existing views and controllers.

Regards, Andrew

[Oliver Rensen]

Hello Andrew,

thank you for the welcome-greetings and the detailed explanation of the MVC-pattern.

All three MVC-components are part of the client. The model is a separate layer between view/controller and the database. When the client books a record, the controller will forward the request to the model, and the model send it over RMI to the database. The database-result will go back to the model, and the model updates the Swing-GUI (and maybe later the JSP-view).

Is my summarization of your words correct or do I have misunderstood your suggestion?

Regards,

Oliver

[Johnny Hunter]

I am currently in the same situation right now. I am wondering about the way that that model needs to update the view. In my understanding of the MVC, I think that you get things right until you say that you have the model passing back data to the view. I don't think you want the model to talk to the view directly. Can't you have the view only talk to the controller, by registering a callback to get the datasource from the controller when the model is done fetching them. This allsows for easy async updates, which the view definitely needs. Let me know what you think. Thanks for the help.

[Andrew Monkhouse]

Hi Oliver,

Yes, that is correct.

Regards, Andrew

[Andrew Monkhouse]

Hi Johnny,

You can have the model automatically update the view if you wish. One way to do that is to use the Observer pattern between them (the View is an Observer, the Model is the Observable object (take a look at the Java class and interface of the same names )). Whenever the model is updated it can automatically update it's views - the model only knows that some class is observing it, so from the model's perspective, it does not know that it is updating a view.

But you can also have your chain as [View]---[Controller]---[Model] in which case the commands go to the controller, which passes them to the model, gets the results back, and passes them to the view. This is how most web applications apply the MVC2 pattern.

Regards, Andrew

[Johnny Hunter]

Thanks Andrew. I've been reading a lot of papers on the Web since I posted this morning regarding MVC. Quite interesting.

Regarding the exam, is there a need to have the view updating each time there is a change in the db (another client can make a reservation therefore changing what can be displayed in another view.) Or doing just a pull and refresh at the user demand is enough for the exam? If the latter is sufficient, then I don't think that I need to make the Model Observable, do I? Thanks!

[Andrew Monkhouse]

Hi Johnny,

Nope - you do not need to update the view with each change to the database.

Regards, Andrew

[Mihai Radulescu]

Hallo Oliver

I sorry for this late reply but I was so catch those days.

You jut say :
"the controller will forward the request to the model, and the model send it over RMI to the database. The database-result will go back to the model".

I think you just give to much responsibility to your model.In my opinion the model is a data conatiner, it holds some data and if there are chenges in its state may be it notifies its observer.The controller is responsible to interact whit the rest of the system.So the controller sends some requset and get some answers (resoults) ,using this answers it modifies the model.If the model uses a observer mechanism then the view gets a notification and ask for the model new state, otherwise (more simple) the controller packs the system answer in to a model and sent it to the view.
Somethig similar you can find In the "Java 1.4 and the Sun Certified Developer Exam." - M. HABIBI