aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Database connection type return problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Database connection type return problem" Watch "Database connection type return problem" New topic
Author

Database connection type return problem

K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2584
    
    9

Hi all, I have a problem with my database connection class. Since there is local mode and network mode, I somehow can't figure out how a method can simulataneously return 2 different objects where the objects don't have any super type/class.

I have thought of using the abstract factory and factory method design pattern. But I get a nowhere. I also thought of using the data access object (DAO) pattern by following the examples in Sun's DAO page but got back my original problem.

My code using factory method looks like:


Now if I use the abstract factory pattern code would look similar but the Database interface would not use used.


With abstract factory I can use the DatabaseFactory's getData and getRemoteData method accordingly. But then I still something to determine which method to call. In my client code, I passed in the mode. So I could do:


Now the problem is I can't use one single variable to store both dbf.getXXX() because they are different types (Data is a DBMain and RemoteData is a Remote). I asked this because if I don't store such connection in my client code, I still have to in my table model class for my JTable.

Please advise how you approach this? Thanks.


K. Tsang JavaRanch SCJP5 SCJD/OCM-JD OCPJP7 OCPWCD5 OCPBCD5
Anne Crace
Ranch Hand

Joined: Aug 29, 2005
Posts: 223
I have my Controller class take care of that with a parameter connectionType that is set in the GUI. I have two connector classes. Whether it is local or remote determines which of these classes is called. They both call Data, and I pass a boolean value local that determines what happens if an IOException is thrown in the Data constructor. If it is Remote, I throw a new RemoteException. I may decide to eliminate the boolean flag, as I haven't really thought this through thoroughly. My solution is very similar to the one in the Monkhouse book. I strongly suggest you grab a copy of it as it is widely used by members of this forum and is full of valuable information. Amazon has it and it shouldn't set you back to much $. Good luck!


SCJP, SCJD
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2584
    
    9

Thanks Anne for your input. I just got this DB connection type thing working - able to load local and remote accordingly.

I used generics for the db creation, which makes me have 2 table models. Similarly I use static method to get the correct table model.

I shall see if all this is better presented when time comes. But I'm happy it's working at least.
Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
1. In order to get rid of the difference between the local and the remote versions of the Data class (or interface?) you should use the adapter pattern.
2. If Data and RemoteData are classes (is not very clear from your description) you should make sure you change this and make your factories return type to an interface.
3. Coding two different GUIs (like two table models), one for each type of connection, is a really bad decision. It may work, but it's gonna cost you (see point 1 for how to solve this).


SCJP 1.4 100%
SCJD 99.5%
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2584
    
    9

Thanks Al for your input. The reason I'm using 2 table models (at least for now) is that I found the remote interface throws RemoteException while the local interface doesn't. So if I include catch (RemoteException) for my local interface, it would not compile. Now if I also throw IOException for all my local interface, that would have changed Sun's given interface right?

Sun given interface has say read method:
public String[] read(int recNum) throws RecordNotFoundException;

If I change it to
public String[] read(int recNum) throws RecordNotFoundException, IOException;

would that violate the specs? If not, then it would definitely make my table model into one cos RemoteException is subclass of IOException.

A point about using my Data/RemoteData classes, in my database connection method, I'm returning the type not the actual class. Eg Data is a DBMain and RemoteData is a Remote. Remote and DBMain super type is what? Object maybe but then Object is class not interface.
Kevin Florish
Ranch Hand

Joined: Jan 06, 2009
Posts: 176
I used a 3 tier approach where I have a presentation layer, services layer and a persistence layer.

All access from the presentation layer to the persistence layer goes through my services layer. Although the contract with the sun interface means you cant throw remote exceptions in your implementation of the interface a services layer can throw IO exceptions. So if your service layer interface throws IO exceptions then your remote interface can throw remote exceptions and then delegate to your data instance:







Java5 Tutorials | Java6 Tutorials | HTML/CSS Tutorials | JavaScript and jQuery Tutorials
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2584
    
    9

Kevin,
I want to ask you about your use of the "Services" interface as your middle layer. I see that for your Services interfaces throws IOException. Does this interface also includes the methods provided by Sun's DBMain interface?

Alex,
I'm looking into the Adapter pattern suggested by you earlier to make my design simpler. I'm not sure if my understanding of the Adapter pattern below is correct.

If I have a new interface call DBAdapter that includes all my local and remote methods by throwing IOException instead of RemoteException (for remote) or not throwing (for local). Then I have a DataAdapter class that implements DBAdapter interface and call the appropriate methods according to the constructor.



Then my client code can use this DataAdapter class or its interface instead of DBLocal or DBRemote.
Kevin Florish
Ranch Hand

Joined: Jan 06, 2009
Posts: 176
Hi K

My Services interface acts aa a "service layer" between my gui and the Data class.

The Data class implements the Sun interface.

My ServicesImpl and RemoteServicesImpl classes delegate to the Data class. So RemoteServicesImpl is along the lines of :

Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
K. Tsang wrote:
Alex,
I'm looking into the Adapter pattern suggested by you earlier to make my design simpler. I'm not sure if my understanding of the Adapter pattern below is correct.

Not really ok. I used a middle tier too (you can check my SCJD results topic for some details about the implementation) and I did not need an adapter. What I would do in your case, I would have something like:


And your factory should return either a DBRemoteImpl, or a DBAdapter, which (in both cases) are DBRemote. Your GUI should work only with DBRemote.
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2584
    
    9

Ah Alex, I think I'm getting what you are saying and what Kevin said earlier too. You are using the remote interface as the adapter so to speak ... just like EJB.

Thinking ahead of myself, wouldn't that mean the stand-alone client also using remote interface?
Kevin Florish
Ranch Hand

Joined: Jan 06, 2009
Posts: 176
When I load up the server I create a unique Data instance that is used by the Network client. This Data instance is delegated to by my remote calls.

My standalone client gets its unique data instance directly from my services implementation and delegates from there.

You could use some check on initial entry to your gui client to see which Data instance to delegate to.
Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
K. Tsang wrote:Thinking ahead of myself, wouldn't that mean the stand-alone client also using remote interface?

Yes, that's the idea. You GUI should only know about one interface. If you want, you can adapt the other way round, rethrow RemoteException as some unchecked exception, and have your GUI always work with the local interface.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Database connection type return problem