This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Design Question ( Data Access )

 
Wilson Liu
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear all,
I am now designing the classes and interfaces for the data access part of the assignment. Would you please give me some comments about my design ?
Here is my preliminary design (I will adopt RMI in the assignment) :

[General]
DataAccess interface - contains all the public methods of the Data class (except the lock and unlock method) as well as the criteriaFind method.

[For Server]
ConnectionService interface - contains "DataConnection getConnection( )" method.
LockService interface - contains void lock( DataConnection conn, int record ) and void lock( DataConnection conn, int record ).
DataServer interface - extends the DataAccess, ConnectionService, LockService and Remote interface.
DataServerImpl class - it will implements the DataServer interfaces. It is a remote object which service the data client request.
[For Client]
DataLock interface - contains the "void lock(int)" and "void unlock(int)" method.
DataService interface - extends the DataAccess interface and DataLock interface.
DataConnection class - it is a Serializable class and implements DataService. Remote client will use the connection object to access the DataServerImpl. For the locking mechanism, it will adapt the DataService's lock(int) method to DataServer's lock( DataConnection conn, int record) method.
Data class - it will be modified to implements DataAccess interface. The client in local mode will actually operate with this class.
Thank you very much !
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not at all convinced by the way you have divorced locking from the DataAccess API. What is the reasoning behind this; in particular, why is locking necessarily not a responsibility for DataAccess?
- Peter
 
Wilson Liu
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter,
Actually, before the above design, the DataService interface contains all
the Data class's public methods (including the lock and unlock) while the DataServer
interface contains all Data class's public methods (except the lock and unlock method)
and extends the LockService, ConnectionService, Remote interface.
The separation of the locking methods from DataService is the result of generalization of the DataService and DataServer interface. Besides, i am concerning if there is any client which use just the DataAccess interface.
I am still struggling for the separation of the locking methods from DataService. Any comment will be appreciated. Thank you very much.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok. What about this.
DataAccess is the interface for "a data source which may be either local or remote". As such, it would include the lock() and unlock() methods which after all are essential for networked operation. Your client application would work with a DataAccess instance throughout; the only place where you manipulate server or local (Data) code directly is the factory method or factory object responsible for instantiating your DataAccess implementation.
You do not, ever, nowhere have code along the lines ofor. In particular, the implementations of methods like lock(), unlock() and close() polymorphically do "the appropriate thing" in the local and remote implementations of DataAccess. The appropriate thing may well be "nothing at all"! In any case, the client code simply calls lock(), unlock() and close() with abandon without worrying whether it is necessary or worrying about what these methods do behind the scenes. That should not be necessary.
Data will implement DataAccess. In addition there will be a networked (Remote) class implementing DataAccess or a DataAccess sub-interface.
Does this help?
- Peter
 
Wilson Liu
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter,
For the remote server, why it need to export the "void lock(int)" and "void unlock(int)" (since they are in the DataAcess interface) ?
For the remote locking, the lock should be associated to the client (in order to prevent non-owner from unlocking the record). Therefore, my remote server will export the "void lock(clientID, int)" and "void unlock(clientID, int)" instead of exporting "void lock(int)" and "void unlock(int)".
For "a data source which may be either local or remote", i will have the Data class and DataConnection class which implement the DataAccess interface. Data client will use the DataAcess interface to access the data. In local mode, client will operate with the Data object directly. In the remote mode, client will operate with DataConnection object which delegate most methods to the DataServer stub and adapt its "void lock(int)" and "void unlock(int)" methods to "void lock(clientID, int)" and "void unlock( clientID, int)" of DataServer stub. Do you think it is okay ?
Thanks
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Wilson Liu:
For the remote locking, the lock should be associated to the client (in order to prevent non-owner from unlocking the record). Therefore, my remote server will export the "void lock(clientID, int)" and "void unlock(clientID, int)" instead of exporting "void lock(int)" and "void unlock(int)".
Ok, and your client-side adapter turns this into the desired lock(int) and unlock(int). Fine (although this is certainly not the only possible implementation).
Data client will use the DataAcess interface to access the data.
But how, if DataAccess doesn't include the lock() and unlock() methods that you put in a separate DataLock interface? Where does DataLock kick in? Or am I getting your design wrong?
- Peter
 
Wilson Liu
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter,

although this is certainly not the only possible implementation

Would you please give me some hints about other possible implementations ?

But how, if DataAccess doesn't include the lock() and unlock() methods that you put in a separate DataLock interface? Where does DataLock kick in? Or am I getting your design wrong?

No, it is my careless mistake.
The Data client will use the DataService interface ( not DataAccess ).
The Data class and DataConnection class implement the DataService (not DataAcess)
.
Thank you very much !
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Wilson Liu:
Would you please give me some hints about other possible implementations ?
Give each client its own server-side object (Connection) to talk to. Then the lock() and unlock() signatures can stay as-is because the Connection object itself gives you the required client identity. Search this forum for the word Connection and you'll get plenty of hits...
The Data client will use the DataService interface ( not DataAccess ).
The Data class and DataConnection class implement the DataService (not DataAcess)
So what is using DataAccess? Why do you need it?
- Peter
 
Wilson Liu
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter,
I have searched the forum and gotten much more idea. I think i need to refactor my design. Thanks alot.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic