I finally come up a brief design although there are still lots of confusion and details. Any comments or advice is highly appreciated! ========================================= I have 3 pachages: client, server and db: db: === DataInterface.java: all the public method in Data.java Data.java: implement DataInterface.java, used in remote mode, lock () and unlock () are implemented here. DataLocal.java: extends Data.java, implements DataInterface.java, used in local mode DataInfo.java: as given FieldInfo.java: as given Server: ======= DataServer.java: DataServerImpl.java: Client: ======= FBNClient.java: the GUI, and user can switch between local and remote modes ClientInterface.java: methods over the database, like searching, booking. RemoteClient.java: implement ClientInterface.java, used in remote mode to connect to the server LocalClient.java: implement ClientInterface.java, used in local mode, thus directly access the local file.
What I am not sure is if I can put the "booking" method on the server in remote mode while put everything on the client in local mode (of course, since no server is involved in local mode). What confuses me is how the client can really implement the operations like "booking", and if this is the case, what the server does here.
Your server side implementation is a good start. I like to suggest the following: 1) Move the searching/booking methods to DataInterface 2) Implement the DataInterface at the client, server and the db layers 3) Create a factory and proxy classes at the client to help you create or find the Data object I don't see any reason for you to extend the Data class. In your design, DataLocal already extends Data class and I don't understand the reason behind implementing DataInterface in DataLocal class. You will get it...keep working on it!
posted 18 years ago
Hi Sai, Thank you very much for your suggestion!
Originally posted by Sai Prasad: Your server side implementation is a good start. I like to suggest the following: 1) Move the searching/booking methods to DataInterface Yeah, this would be a good idea so that both remote and local mode can access them consistently. 2) Implement the DataInterface at the client, server and the db layers I do not think I am very clear here. Why do we need to implement at the 3 layers? Could you please give me more hints? 3) Create a factory and proxy classes at the client to help you create or find the Data object I don't see any reason for you to extend the Data class. In your design, DataLocal already extends Data class and I don't understand the reason behind implementing DataInterface in DataLocal class. I am not sure about it either. The reason I initially wanted DataLocal to extend Data and implement DataInterface is that I think there might be some methods common in local and remote modes, and some with different implementation. But I feel I am confusing myself. : confused : Another question is I am not sure what you mean by "DataLocal already extends Data class". Thanks again, Sai. You will get it...keep working on it!
Originally posted by Sai Prasad: 1) Move the searching/booking methods to DataInterface
I strongly disagree. Really, really strongly. Data is a general-purpose, completely reusable database engine. DataInterface is the interface implemented by Data. It can well include other general-purpose database-level functionality, such as lock(), unlock(), and criteriaFind(). Booking and (high-level) searching are application-specific, completely non-reusable functions in a business API. They are on a completely different level of abstraction compared to the DataInterface. Never the twain should meet. They could not be more different -- different in type of functionality, different in abstraction level, different in degree of reusability.
2) Implement the DataInterface at the client, server and the db layers
If you carefully analyse the requirement that you create an object implementing all the public methods of Data (at least that was in my instructions), you will see that this only makes complete sense if this DataInterface represents the split between client and server. You can get by with just two DataInterface implementations: Data itself, and the multi-user networked version of Data. (Oh well, maybe there are three if you count the RMI stub too). - Peter
posted 18 years ago
You asked: 2) Implement the DataInterface at the client, server and the db layers Why do we need to implement at the 3 layers?
Your DataInterface contains all the public methods in Data class. So you will be implementing this at the db layer. When the user selects remote mode, the client side data factory will find the remote implementation (which in turn implements DataInterface), give that instance to the client proxy (not the _Stub..your own class) and return the proxy to the GUI controller. To implement this design, you will be implementing DataInterface on the client side When the user selects local mode, the client side data factory will create a new instance of the Data class and which already implemented the DataInterface and set this Data to the client side proxy. My client side proxy also implements the DataInterface. This what I meant when said implement DataInterface at the client layer. ---------------------------- You asked: Another question is I am not sure what you mean by "DataLocal already extends Data class". DataLocal in your case is a sub class of Data. That is what I meant above. I didn't sub class the Data [ April 15, 2002: Message edited by: Sai Prasad ]
Ew. You guys are ugly with a capital UG. Here, maybe this tiny ad can help:
Devious Experiments for a Truly Passive Greenhouse!