• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Database connection type return problem

 
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
K. Tsang
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).
 
K. Tsang
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:





 
K. Tsang
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 192
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 158
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 192
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 158
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic