Is my MVC design under RMI reasonable?

[song bo]

I use MVC for my architecture design.The local mode works fine,but there is a little problem under rmi mode.
I define 3 interfaces for model,view ,controller.then I implement these interfaces separately for Local mode and RMI mode.under RMI mode,the View and the Model are remote objects,the controller is registered to the View,the View is registered to the model.when the data of the Model is changed,it will refresh all the Views registered.

public class RmiBookModelImpl extends UnicastRemoteObject implements BookModel {
private ArrayList observers = new ArrayList(10);
public void addObserver(BookView bv) throws RemoteException{
synchronized(observers){
observers.add(bv);
}
}
public void update(int recNo, String [] data)
throws RecordNotFoundException, RemoteException{
BookView bv;
Integer recObj = new Integer(recNo);

//db is the Data class.
db.update(recNo,data);
for (int i=0; i<observers.size(); i++) {
try{
bv = (BookView)observers.get(i);
bv.update(recObj);
}catch(Exception e){
//if failed to update.the server will believe the observer is shuted down.so the server delete it.
observers.remove(i);
}
}
}
...
}

the problems:
1.Refreshing all the view of the clients is slow.especially some clients is disconnected.
2.when the network of one client named "A" is dropped,at this time,another client book a record.the model will delete the client "A" that could not be refreshed.after a while the network of client "A" resume normal,it can be booked but the View can not be refreshed for ever.because the view of "A" has deleted.
What should I do?I could not has a idea.please help me.

[Andrew Monkhouse]

Hi Song,

Originally posted by song bo:
I define 3 interfaces for model,view ,controller.then I implement these interfaces separately for Local mode and RMI mode.

Do you mean that you have one view for displaying records when you are in local mode, and one view for displaying records when you are in networked mode?
If so, then I think you will loose points in the OO section of the marking.

Originally posted by song bo:
1.Refreshing all the view of the clients is slow.especially some clients is disconnected.

Providing automatic updates to every client when any client makes a booking is not a requirement of the assignment.
But if you are doing it, you could look at whether you want a separate thread to handle the update. This means that the server will be able to progress more quickly to the next connected client in order to update them.

Originally posted by song bo:
2.when the network of one client named "A" is dropped,at this time,another client book a record.the model will delete the client "A" that could not be refreshed.after a while the network of client "A" resume normal,it can be booked but the View can not be refreshed for ever.because the view of "A" has deleted.

How is client A reconnecting? (Or alternatively, how is your server noticing that client A is disconnected?) Both should happen together, so you should not be able to get one side believing that the connection has dropped and the other side believing that the connection is still up.
Regards, Andrew

[song bo]

thanks Andrew's suggestes.

Do you mean that you have one view for displaying records when you are in local mode, and one view for displaying records when you are in networked mode?
If so, then I think you will loose points in the OO section of the marking.

I use BookGUI for displaying records.BookGUI is the user interface.user'action is implemented in the view by inner class.
the view for networked mode is a remote object,extend UnicastRemoteObject,but the handler of the user action is same with the view for local mode compeletely.
here is code of my view and controller interface:

/**
 * This is a interface that define the services supported by the view.
 *
 * @version 1.0
 * @author songbo
 */
public interface BookView extends Remote{
/**
 * This method register a user operation listener to the inner list.
 * user operations include search,modify,refresh acted on the GUI.
 *
 * @param controller handle the user operations that need change
 * the model state.
 */
public void addController(BookController controller) throws RemoteException;
/**
 * Update the data to the book GUI.
 *
 * @param data java.lang.Object
 */
public void update(Object data) throws RemoteException;
}
/**
 * This is a interface that define the services supported by the controller.
 *
 * @version 1.0
 * @author songbo
 */
public interface BookController {
/**
 * This method retrieve the records spcified by the parameter from the 
 * book model and update the book view.
 * This method is called by the view when user do a "modify" operation.
 *
 * @param recNo a integer array of all the record No stored in the view.
 */
public void refresh(int[] recNo) throws Exception;

/**
 * This method handle user's "search" operation.get the search result 
 * from the book model and update the book view.
 *
 * @param criteria a String array that describe the search condition.
 */
public void search(String[] criteria) throws Exception;
    /**
 * This method handle user's "modefy" operation.call the modefiy() method 
 * of the book model to modify the data.
 *
 * @param rec the number of the record.
 * @param data a String array that mapped a record.
 */
public void modify(int rec,String[] data) throws Exception;
}

maybe my OO design is bad.
but under MVC, the view must be registed to the model and notified by model whose state is altered.
so,I decide to design the view for remote mode as a remote object.
now ,I am not for sure.SCJD is a course of studying,I want to process it well so that apply it to another similar project.

[Andrew Monkhouse]

Hi Song,
I take it that your Model is on the server then. Is your Model the database itself? Or is it a model of the database?
This is getting a little esoteric, but what I am trying to get at is that the Model in an MVC design is meant to abstract the entire database for the Views. The View should not be aware of:

what type of database is connected
The view should not care whether you are connecting to the custom database you wrote for Sun, or to an Oracle database. This means that the View can call business methods on the Model (e.g. call a bookRecord() method, rather than calling the lock(), read(), update(), unlock() methods). This means that if the database later changes to an Oracle database, only the code in the Model will need to change - there will be no need to modify all the Views to make them handle SQL.

or what the underlying table structure is
Similar to the point above.
Your View should not worry that the data is currently stored physically in fixed length strings. It should be able to handle the data in a format that is right for the application as a whole. This means that if you know that a particular field is numeric, and you wanted to treat it as numeric in your Views, the Model would be the correct place to change it from it's current String representation into an Integer. Again, if we later changed to a different database which did store numbers as numbers, this will be hidden by the Model - the View will still just be getting an Integer.
Likewise we currently have one flat file containing all the fields. Later these might get split out into two or more tables, or additional tables might be added to the database. The Model can hide these physical implementation issues from the View.

or how it is connected
Right now you have chosen to use RMI. Later the client may choose to use Sockets or some other communcations paradigm (JMS, SOAP...). If you have hidden the communications behind the model, then you will not have to modify the Views to handle this change.

Likewise the Model should be completely unaware of what sort of Views are attached. You might have a View which is a Swing application (like we have now), or a View which is a JSP page, or a View which is a standalone application doing work on the data with no client screen attached (a view that you can't see ). The Model should be able to accept requests for access to the data from any of these views, and if the model and the views use the Observer design pattern, then the Model should be able to propogate updates to any and all of them.
Note: In my description, I have covered some items that you are already doing - I have done this so that others who may be reading this can get a better understanding of what the MVC should give us.
I asked before whether

your model was on the server.
This would mean that at a minimum your Controller(s) and possibly your View(s) need to be aware of the communications protocols involved.
Right now you might only have one View. But in the future that might expand to 10 Views, all working off the same Model. And if someone then decided tp change the network protocol, all 10 Views and the 10 Controllers will need to be modified.
You have already seen this: you have been describing two Views: one for networked mode, and one for standalone mode. We now have two classes that are doing essentially the same thing, which is not very good reuse of code, and is prone to introduction of bugs.

your model is the database
If this is the case, then ask yourself whether there is any work done on the data at any point before it gets to the View. For example, do you convert any of the Strings into Integers, or do you convert the array of record numbers returned by the call to find() into an array of Records() (or an array of String[])).
If so, then isn't this sort of conversion likely to be common to the entire application? In which case wouldn't this logic be better in the Model rather than in the View? (You don't really want much logic in the View - it is only meant to be displaying the data, not doing large amounts of database specific processing.)
In which case, there is a strong argument for the Model being a model of the database, not being the database itself. (Perhaps that's why it is called a model )

Now if you pull the model over to the client side, all this abstraction is possible. The View no longer needs to know about the communication protocol in use, or any of the other issues I mentioned. This means that you will only need one View, rather than a separate view for networked or stand alone mode.
Regards, Andrew

[song bo]

Thanks andrew's so detailedly reply,I have read it for several times.it's useful to me.

I take it that your Model is on the server then. Is your Model the database itself? Or is it a model of the database?

Yes,My Model is the model of the database.
Ago,I thunk that model must hold the data,in the application that need database supported, the data of the database is the state of the model,if the data is changed,imply the state is changed too.
in my oo design,I always feel that it's a little farfetched.Now,I have known the MVC design deeply again from another point after reading your reply.I decide to design the architecture again.

I asked before whether
1.your model was on the server.
This would mean that at a minimum your Controller(s) and possibly your View(s) need to be aware of the communications protocols involved.
Right now you might only have one View. But in the future that might expand to 10 Views, all working off the same Model. And if someone then decided tp change the network protocol, all 10 Views and the 10 Controllers will need to be modified.

2.your model is the database
If this is the case, then ask yourself whether there is any work done on the data at any point before it gets to the View. For example, do you convert any of the Strings into Integers, or do you convert the array of record numbers returned by the call to find() into an array of Records() (or an array of String[])).
If so, then isn't this sort of conversion likely to be common to the entire application? In which case wouldn't this logic be better in the Model rather than in the View? (You don't really want much logic in the View - it is only meant to be displaying the data, not doing large amounts of database specific processing.)

I could not understand still ,do you mean the model is the business model,if so,I think the model is on the server for certain.let me give an example,if you have distributed many client programms and they have all worked fine.But after a time,the boss decide to change the book rule.because the business is wrapped in the client,so you have to modify every client programm and distribute again,if you put the model on the server,you only modify the server code,the clients do not know,because the client only guther the data that user input and pass it to the model,so it need to change.

[Andrew Monkhouse]

Hi Song,

I could not understand still

OK - if we think in terms of a "pure" MVC design, then we would have one class which is the model. (That Model class may be (and usually is) a Fa�ade to other classes.)
So my question is: where is this class that is the class that acts as a Model - on the client side or on the server side?

if you have distributed many client programms and they have all worked fine.But after a time,the boss decide to change the book rule.because the business is wrapped in the client,so you have to modify every client programm and distribute again,if you put the model on the server,you only modify the server code,the clients do not know,because the client only guther the data that user input and pass it to the model,so it need to change.

Whether a change like this can be done without modifying the clients really depends on what type of change it is.
The disadvantage of this paradigm is that any change will cause an outage on the server. So even if only one or two clients want this change, all clients are going to have connectivity disabled for a while.
Plus it is harder to do a limited update of clients. For example, if 10 of your 100 clients want some new functionality, but you do not want the other 90 to get it. That would be hard to achieve under your paradigm, but easy to achieve if the logic is in the client software.
By the way - I am not saying you are wrong. Either your way or my way can be "correct", as long as you state what you have done and why you did it in your design decisions document. I am just giving you some more things to think about
Regards, Andrew

[song bo]

thanks andrew.
I am very glad to discuss my question with you.Not only programm but also english .I will not Providing automatic updates to every client when any client makes a booking .and I will design one view and one controller for any type of model.so my new artichiture as follow:

                       View
                      /    \
                     /      \
                    /        \
                  Model-------Controller
                 ^    ^
                /      \                
               /        \
    LocalModelAdapter  RmiModelAdapter
           |                 |
           |                 |------>Data
           -------------------