wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes How to handle Data and RemoteData Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "How to handle Data and RemoteData" Watch "How to handle Data and RemoteData" New topic
Author

How to handle Data and RemoteData

Jeff Shen
Ranch Hand

Joined: Sep 04, 2002
Posts: 31
Using the Facade pattern to deal with all data related operations is an excellent idea, however my question is if the LocalData dose not implement DataInterface but the RemoteData implements the Datainterface, how can I use unique data object to represent both the LocalData and RemoteData.
Regards,
Jeff
Richard Solomon
Greenhorn

Joined: Sep 12, 2002
Posts: 11
Originally posted by Jeff Shen:
Using the Facade pattern to deal with all data related operations is an excellent idea, however my question is if the LocalData dose not implement DataInterface but the RemoteData implements the Datainterface, how can I use unique data object to represent both the LocalData and RemoteData.
Regards,
Jeff

Hi Jeff
What I suggest is that you create some sort of client-side proxy interface and hold the reference to the proxy interface in your code exposing all the methods relevant to the Data class, so what this means is that you would create a common interface and then create two concrete classes:
LocalDataProxy & RemoteDataProxy
the internals of these classes will know exactly how to call the data it relates to eg. LocalDataProxy would call methods on the LocalData class and RemoteDataProxy would call methods on the RemoteData class.
Of course there are many other ways of achieving this, but within the context you are using this may be the most effective choice
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Jeff,

... if the LocalData dose not implement DataInterface but the RemoteData implements the Datainterface, how can I use unique data object to represent both the LocalData and RemoteData.

LocalData should implement DataInterface. That way the Facade is oblivious to whether it is in remote or local mode. Even though you will make meaningless calls like lock() and unlock() in local mode, it makes the code very clear and maintainable.
Hope this helps,
Michael Morris


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Sarita Gupta
Ranch Hand

Joined: Aug 12, 2002
Posts: 43
Hi,
Richard wrote:
What I suggest is that you create some sort of client-side proxy interface and hold the reference to the proxy interface in your code exposing all the methods relevant to the Data class, so what this means is that you would create a common interface and then create two concrete classes:
LocalDataProxy & RemoteDataProxy

Now, can i just check is it better to expose all the public methods of Data Class or only to expose the business methods such as doSearch(), doBooking(), etc... I prefer to have my business logic on the server side... I thought that's the way to go... pls comment...
Sarita


There are no great people in this world, only great challenges which ordinary people rise to meet.
Richard Solomon
Greenhorn

Joined: Sep 12, 2002
Posts: 11
Hey Sarita
What I would suggest is to probably go ahead and expose all of the public methods of the Data class in the proxy interface. That way the code needs fewer modifications in the future, should FBN require someone to add delete, insert functionality etc. Also the person maintaining your code could very easily see what the particular method would do in relation to the Local/Remote database, without first having to decipher whatever you may have named your methods.
plus it follows good Adapter Pattern design principles which state:
Creates a common interface for a set of classes used by client code, which communicates with a subsystem (which in our case would by the local and remote databases) where classes are of incompatible types (in your case DataInterface for remote and something else for local).

Hope this helps
Sarita Gupta
Ranch Hand

Joined: Aug 12, 2002
Posts: 43
I've heard from Richard, Micheal what's your say on this... which is better business logic on server side or client... just as a general consideration when developing any client server application.
My thinking is that by exposing all the public methods of Data class, we are giving full controll to those developing the client to add/ modify and update the data as they like. By exposing only the business methods we ensure that the data in saved into the database correctly cos it's only the server side who will be dealing with the db and this is carried out with proper locking mechanism.
Assuming others are using the FBNServer to develop their own clients and if a developer forgets to call the lock() method when doing the booking... don't u think the db will be messed up...
Pls anyone... convince me if am wrong here...
Sarita


Sarita
[ September 13, 2002: Message edited by: Sarita Gupta ]
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Sarita,

My thinking is that by exposing all the public methods of Data class, we are giving full controll to those developing the client to add/ modify and update the data as they like. By exposing only the business methods we ensure that the data in saved into the database correctly cos it's only the server side who will be dealing with the db and this is carried out with proper locking mechanism.

Well, if you take a poll of developers' opinion on how to develop a 2-tier client server system, which is what this assignment was designed to be,
you would probably wind up with half saying put the business logic on the cliet (fat client) and the other half saying put it on the server (fat server). I chose to put the business logic on the client in a DataFacade which was the only class that had knowledge of Data's public interface, not because I necessarily feel that that is a better approach but because of the reqirement in the instructions:
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration.
Now, having said that, I went contrary to the instructions that stated that the candidate should either extend or modify the Data class. I did neither, arguing that a third alternative was better: composition. I definitely lost no points for taking that position. So, if you feel strongly about only having high-level business methods on the client and implementing the business logic on the server then do it that way and expand on the argument you gave above in your design choices document. I feel that if you convincingly state your case, that you will not be penalized by the assesor.

Assuming others are using the FBNServer to develop their own clients and if a developer forgets to call the lock() method when doing the booking... don't u think the db will be messed up...

That's just another good argument for your design choices document. It's your card game, so if you want to slightly alter the rules for good reason then do it.
Hope this helps,
Michael Morris
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: How to handle Data and RemoteData
 
Similar Threads
Exceptions Handling
why do we need RemoteInterface?
Overall Architecture
DataAccessFactory Dilemma
Writing Data Client