I have a database that I would like to connect to on an AS400. Right now my basic design is to have a class that deals with the database, and can execute queries and store the result set (I then will have a getresult() method). Is this a good way to start out? I have begun writing the code, and can print the results out, but would like to display them in a JTable, which I find to be very confusing. Any help on basic design or examples would be appreciated.
I usually reserve a class to handle the connection itself (e.g. DBConnectivity.java). Other classes which utilize the DB can either extend DBConnectivity, or use composition to gain access to the actual DB. When modeling the other classes, I usually think, how does the data logically seperate itself? Is it an inventory system? If so, I might have classes such as Lingerie, Sportswear, Casual, and so on, you get the idea. Each of these classes utilizies the database in a specialized way, specific enough to warrant its own class.
Finally, you'd have your GUI class, which drives the GUI engine. [ June 07, 2004: Message edited by: Jeffrey Hunter ]
Joined: May 19, 2004
Would it make sense to have a connection (with driver and such) and then extend that for each set of data to put into a JTable? This is what my plan has been. If I extend the connection class, then will I need a separate table model class before putting it in a JTable? Sorry to ask such basic questions but I am completely lost on this, as this is my first "real" Java program.
Originally posted by Cory Lutton: If I extend the connection class, then will I need a separate table model class before putting it in a JTable?
I remember not too long ago when I was pretty green, and I was hesitant to write multiple classes. I tried to put everything in one, neatly packaged, ready to go class. But, the downfall of this strategy is that inevitable part of the software lifecycle -- the maintenance phase. Your code will have errors, clients will want new features, and so on. Remember, memory is cheap! What is not cheap is time. When I have to wade through a quagmire of code with no clear seperation of logic, and my boss is breathing fire up my ass wondering why it's taking so long to implement those flashy new features, well, no one wins in this situation except maybe the new programming team that gets hired by a pissed-off client.
I'll give you an example (I'm in a ranting spell, so bare with me). I was project lead on a recent web-based system which relied heavily on a database back-end. Now, I had one class that controlled all connections. Hence, it stored the DB IP, port, username, password, monitored connections, etc. Now, we shipped the system off to the client and everything seemed peachy, until they tried to run the sytem on their database. I forgot to change the database IP from my development machine, to their database server! So you can see the nightmare this could have been if all 15 classes had their own database implementation. You would have to go through each one of those 15 classes and manually change the IP address. Fortunately, one class controlled the connection, so the fix was as simple as changing one line of code in the DBConnectivity class.
So, I guess the moral is, don't be afraid to make classes, they are your friend, and those programmers who inherit your code will be grateful.
Joined: May 19, 2004
I always like to break things down to small pieces when possible, I'm new to Java but have done some programming in RPG, CL, and VB in MS office applications (Excel mainly). My current task involves our new ERP system, and making a "bolt-on" (boy I hate those words) to keep our sales dept happy with the configuration process of customer orders. I took your previous post and put it into effect, that is exactly what I was looking for. If only I can figure out this resultset - tablemodel - JTable stuff, I'll be good to go.