aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Single Data Interface Justification Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Single Data Interface Justification" Watch "Single Data Interface Justification" New topic
Author

Single Data Interface Justification

Jason Moors
Ranch Hand

Joined: Dec 04, 2001
Posts: 188
Hi everyone,
I'm trying to justify the use of a single data interface in my design document. In my view the DataAccess interface provides the client access to the database (API), whilst hiding the actual implementation i.e local or remote from the client. If this is true, then client must therefore catch both DatabaseExceptions and RemoteExceptions.
The implication of this is that the DataAccessLocal implementation must delcare that it throws RemoteException as it extends remote, whilst never actually throwing the exception. I would argue that if a client only required local mode that it could us the Data class.
Any comments?
Thanks
Jason.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

If this is true, then client must therefore catch both DatabaseExceptions and RemoteExceptions.

Actual in my DataAccessFacade, which the client uses. I catch the DatabaseException, then I also catch Exception, in the catch of the Exception, I create a new DatabaseException, put a nice message in it and then throw the DatabaseException. This way the client only has to catch the DatabaseException.

Also why not just have your DataAccess interface throw Exception? It is generic and allows you to throw the more appropriate exceptions in the implementation class.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Jason Moors
Ranch Hand

Joined: Dec 04, 2001
Posts: 188
Hi Mark,
I'm in two minds about the interface throwing Exception, whilst it provides flexibility for future implementations to throw exceptions derived from Exception, it means that the client class must catch Exception. This in my experience is a bad thing as you may catch exceptions which should propagated higher up the application.
Thanks for you're input
Jason.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
The implication of this is that the DataAccessLocal implementation must delcare that it throws RemoteException as it extends remote, whilst never actually throwing the exception.
Not true. The implementation class need not declare any exceptions. But any remote interface it implements will need to declare throws RemoteException for all methods, and the rmic-generated stub class will have methods that really can throw those exceptions. But

Here Data implements two interfaces, identical to each other except that one is remote and the other isn't. You can use Data locally and refer to it using the DB interface, or you can use it in network mode and refer to it with the RemoteDB interface.
The main problem I see with this is that it may not have sufficient separation between the networked code from the non-networked code, as required in the instructions. When in local mode we're still instantiating a class that extends UnicastRemoteObject, even though it never gets used as a remote object. So that's a bit weird, but I think it may be acceptable. Personally I'd rather have separate classes to handle the network connection, but this is an option at least.


"I'm not back." - Bill Harding, Twister
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Single Data Interface Justification