Get your CodeRanch badge!*
The moose likes JDBC and the fly likes Analysis Paralysis - JDBC Application Options Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Analysis Paralysis - JDBC Application Options" Watch "Analysis Paralysis - JDBC Application Options" New topic
Author

Analysis Paralysis - JDBC Application Options

Rw Adams
Greenhorn

Joined: Oct 28, 2011
Posts: 10
Hi all, I am an experienced (10+ years) mainframe C & ASM developer who has started to try and learn Java & OO programming. It's mostly self taught, though I have had some in house company training on OO & Java.

Anyways, I want to develop some simple Swing applications using JavaDB and JDBC to obtain the data from multiple tables (2-3 in each app) in the database. That's about where my certainties end and my confusion begins. Ideally, I want a way that will allow me to obtain a SQL statement, bind the needed parameters (if any) and then execute the against the database. I want the code (connection, load SQL statement, binding and execution etc) to be reusable as much as possible. I have come up with a few approaches...

#1 I think I could use an open source framework like Hibernate or myBatis (use to be iBatis) to get the data from the database but
pros: achieves my goal
minimum of coding
cons: lot's of configuration / setup to get things working
don't know that I will learn much JDBC
I like knowing what's going on under the covers

#2 I could go with coding the DAO classes myself:
pros: would learn more about JDBC API
good fit with OO concept of encapsulation (1 DAO per table)
cons: not very reusable (I would have to code a new DAO class for each table I want to use)

#3 I could try and write something myself to accomplish my goal:
pros: would learn JDBC API better
would become more proficient at design
cons: don't have much OO design experience
seems like "reinventing the wheel" because of #1
could end up with a poor design, since I don't have any experience @ OO Design

I keep changing my mind about what approach would be the best. The cons for each approach all big and so I am not sure what may be the lesser of my evils. I have thought about building the statements dynamically, but that does not seem much different from the "static" approach of #3. It also seems to have the same cons. I am also afraid my limited OO Design experience may be keeping me from coming up with something I had not thought of... I would appreciate the groups thoughts & opinions!

Thanks!
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18118
    
    8

Rw Adams wrote:I want the code (connection, load SQL statement, binding and execution etc) to be reusable as much as possible.


Your question is much too wide-ranging for me to address. But here's something I could comment on:

Don't set up a goal of making something "reusable". At least, not if you haven't ever done that thing before. They might have told you in your OO training that things should be reusable, but perhaps they didn't go into detail about how to achieve that. It's not like you can get out your reusable-coloured magic marker and write "Reusable" on a piece of code. It doesn't work that way, not unless you thoroughly understand the problem domain where that code resides.

Here's the bottom-up way to do it: Write some code for a specific purpose. Like code to access your Deliveries table, or whatever you might have. Don't worry about whether it's going to be reusable, because it isn't, yet. Then write some more code for a similar purpose, like your Bank table or whatever. Then do that a third time. Make sure that everything you've done is working reliably. At this point you should start noticing common features of the three pieces of code you just wrote. Now you can abstract those common features into a basic framework. This may require uprooting the code you already wrote; that's fine, we call that "refactoring" and it's a standard part of OO programming. (And even non-OO programming for that matter.) But don't go too far, don't try to abstract features which only look vaguely similar.

The next step is to write some more similar pieces of code which use the basic framework you just created. You may find this new code doesn't work well with the framework because it has something which is different from what you thought was a common feature from the earlier pieces of code. At this point you might want to make your framework more complicated to support this variation, or you might want to remove the feature entirely. That sort of decision gets easier the more times you have to make it.

could end up with a poor design, since I don't have any experience @ OO Design


That's certainly possible. Perhaps even probable. But the best way to get that experience is to start making designs. You could post your proposed designs here for people to comment on, if you liked.

steve souza
Ranch Hand

Joined: Jun 26, 2002
Posts: 852
<<It's not like you can get out your reusable-coloured magic marker and write "Reusable" on a piece of code.>>
I wish you would have told me that before I bought my marker! Well at least the color was pretty.


http://www.jamonapi.com/ - a fast, free open source performance tuning api.
JavaRanch Performance FAQ
Joe Areeda
Ranch Hand

Joined: Apr 15, 2011
Posts: 294
    
    2

I worked my way from ASM and C over the years and ended up with Java, Swing, and jdbc being my preferred environment. It's been a while since I transitioned to OO and event based GUIs but I still remember the transition as being difficult.

My opinion of Frameworks is mostly ambivalence. I've worked with a few and my experience has been when the designers wanted the same things I want for this project they are nice otherwise they are more of a hindrance than a help. Perhaps I never spent enough time aligning myself to their view of the world.

I do tend to build objects into my own framework kind of libraries. I have several object built around JDBC access to mysql and sqlite databases. As an over generalization I think if you are going to write SQL statements you are fine with JDBC level access. The higher level frameworks I've used like to write their own SQL based on GUI forms of some sort and populate GUI widgets with results.

I highly recommend an IDE, my favorite is NetBeans but Eclipse is in the same league. Those are the only 2 I've used enough to comment.

Good luck. if you're like me you have some work to do before the concepts of encapsulation, inheritance, and polymorphism become an integral part of your coding style and you realize the full benefits.

Joe


It's not what your program can do, it's what your users do with the program.
Rw Adams
Greenhorn

Joined: Oct 28, 2011
Posts: 10

Paul Clapham wrote:
Don't set up a goal of making something "reusable". At least, not if you haven't ever done that thing before. They might have told you in your OO training that things should be reusable, but perhaps they didn't go into detail about how to achieve that. It's not like you can get out your reusable-coloured magic marker and write "Reusable" on a piece of code. It doesn't work that way, not unless you thoroughly understand the problem domain where that code resides.



What about when I can "see" something as reusable? It seems like wasted effort for me to keep coding the same or similar logic for a select for different classes, when I should be able to come up with a way that allows me put some code in a separate class. Then I can use that class each time I select from any table. Is it better for me to encapsulate objects on a table by table basis instead of trying to make something that is reusable? At least until I have done some design myself? Your comments on re-usability are right on as far as not digging into the detail of how to achieve it. Maybe that's my whole problem, I'm trying to make stuff reusable without really knowing how to do it.... :-)

At this point you should start noticing common features of the three pieces of code you just wrote. Now you can abstract those common features into a basic framework. This may require uprooting the code you already wrote; that's fine, we call that "refactoring" and it's a standard part of OO programming. (And even non-OO programming for that matter.)


Does reusable code/classes tend to come from refactoring in OO? Or can it be achieved during design with a more experienced designer also?

Thanks!
Joe Areeda
Ranch Hand

Joined: Apr 15, 2011
Posts: 294
    
    2

Rw Adams wrote:Does reusable code/classes tend to come from refactoring in OO? Or can it be achieved during design with a more experienced designer also?

I don't think the answer to this is not much different in OO languages vs C or ASM.

Both methods are useful. You can design a library from the beginning and also redirect the urge to copy/paste in to cut and paste into a new method.

The big difference with OO is when refactoring you can create a base class or move things into the base class (or interface) if the Objects are similar.

Since Java does not have the concept of global anything you end up with Utility classes like System and Math with static functions.

I find I'm much better at defining reusable Classes and methods the second time I want to use them so I tend to spend less time in the initial design and quickly build a prototype. Then redesign and refactor a lot after people have had time to tear my concepts to pieces. I throw out a lot of code but what remains is much higher quality. The refactoring tools in the IDE, Java's strong typing including generics and excellent compile time diagnostics help a lot.

Joe
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4634
    
    5

The usual term for what you want is really ORM, Object to Relational DBMS Mapping. DAO is just one type of ORM. Over the past couple of decades, I've written a number of ORMs. I always like mine better than the frameworks that everyone else likes.

A couple of observations:

1) No matter what you do, there is a bunch of duplicated "code" for each class. Sometimes it is really code, sometimes XML or other meta-language, sometimes annotations. Doesn't matter. The key is that you have to bind the column/attribute in the RDBMS table to a variable in your objects, and somewhere, you have to specify that binding.

2) If your application has a fairly small number of tables, say 10 or fewer, it really doesn't matter what you do. There is not enough "code" here to really worry about.

3) if your application has say 50 tables, you have a challenge. Now its an engineering issue, with lots of trade-offs.

4) if your application has more than 100 tables, shoot the schema designer.

5) none of the frameworks that I've used do a good job of handling the hard stuff. The four way joins. The nested contained objects. These topic exactly what you hope that a good framework/solution will provide.

6) you have to decide how portable/reusable you want all this. If you write to JDBC, you have a fairly good level of isolation. But sometimes you really want to write MySql or Oracle or SqlServer or .... specific code to really get it to work. When you do that, you lose all hope of translating to another vendor when Oracle|Microsoft|IBM|whoever charges too much, screws you over, etc.

Knowing nothing about your real application, domain, criteria, etc. so I can't make any sort of an informed analysis, I say: "implement it in Hibernate" and after a month, decide if its good enough for what you really need.

Rw Adams
Greenhorn

Joined: Oct 28, 2011
Posts: 10
Thank You Pat, Joe & Paul,

Your comments have helped end the analysis paralysis so to speak. I even learned a thing or two in the process. I am looking at some pretty simple and small problem domains. I don't expect more than 5 tables for each of the problems I am trying to solve. Since the number of items is so small, I am going to go with writing the code myself to access the tables. Some of the stuff will hopefully be re-factored and improved, it's certainly happened with the C code I have written over the years, almost always for the better.

Thanks!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Analysis Paralysis - JDBC Application Options
 
Similar Threads
Structure for Data Access Object(s)
Idea for a new book. Effective Programmer.
Need guidance
What's it all about man (this Java thang)
Converting a String to Proper Case