I’m working on an issue tracking application and I have a problem that occurs over and over. The purpose of the application is to create and issue/case which consist of multiple tasks/task orders. My problem is that I don’t know how to pass that information between different parts of the application (different swing components). I started with creating objects that mirror my database tables, but I soon realized that these objects do not carry all information I need.
A clear example of my problem can be seen on the screenshot bellow. The right side of the panel creates a task object with taskId (foreign key in the database), employeeId and some information. The left side of the panel creates an issue which holds a list with tasks. Once created the issue will be saved to the database. The problem is that I can’t use my task objects to display all tasks in the JList “List of tasks” since I have only foreign keys and the name of the task is contained in a different (Task) object.
To summarize my problem, I have classes that mirror may database tables, but I often need to pass around information from multiple tables. Are there any design practises that resolve this issue? I did some reading on data transfer objects but I not sure if this is their purpose.
I’ll be thankful for someone can point me in the right direction, so I can to some reading on the right topic. Thanks in advance!
posted 8 months ago
I forgot to mention that I use JDBC to manage the database.
Its little difficult to understand whats going on with what you have provided (though the image shows a lot of design). But, here are some thoughts:
The Database Tables:
Two tables - Issue and a Task.
Issue table has a PK with Issue Id (or Case Number) and a Task table has a PK of Issue Id + Task Id (or Task Number). This is because, an Issue has multiple tasks associated with it.
A Issue class and a Task class.
- The Issue class has the issue related info only. No Task related info is there as attributes.
- The Task class has the task related info, including the Issue its associated with as an attribute.
The GUI and Models:
When a new Issue is created a new Issue table row gets inserted. And as new tasks are added to it, new Task rows are added to the Task table. The model needs to be like this:
The task-issues data is cached as a Map collection. The map's key is a Issue and the map value is a collection (a List collection, perhaps) of Task objects.
The GUI (in the posted image) shows a JList with Tasks related to an Issue. The JList is built using a data-model of type ListModel. In the task-issue map data, instead of using a List (as I mentioned in the previous paragraph) of Tasks, a ListModel of type Task can be used.
Initially: Read data from the database tables.
Create objects and build the task-issues Map data.
Populate and refresh GUI.
Add new data: Enter an Issue and related Tasks.
Update the model (issue-task map), database tables (each Task at a time) and refresh the GUI.
I don't know if what you are doing right now is similar or different. But, think about this and your own design and see if something is useful from this.
Many people make the mistake of starting by writing the GUI. You should start by writing the model; try reading from the database tables first. If you actually have two separate databases, you may need to read them separately and then combine the results. One possible way to do that might be to create a third database and copy the results into that. Just an idea.
posted 8 months ago
Thank you all for the replies, I really appreciate it! I will definitely look closer to object maps when I start refactoring the project. It is my first java application and perhaps that most important lesson I learned while working on it was what devastating effects a bad design can have. I’m yet to learn how a good design looks like. Many of the examples I’ve seen in books or on Internet explain simple situations often with just one database table or at most tow tables with one-to-many relationships. I haven’t had the chance to see how more complex application with multiple tables, many-to-many relationships, and different GUI components looks like. Thanks again for your advices!
In the desktop GUI application programming try to keep the model and view separately; this is applying Model-View design principle. The controller aspect can be developed based on requirements. One need not be rigid about this and often times in smaller applications it is possible these can overlap.
An application with a layered architecture, for example, UI layer, application/UI data model and the database access (like using JDBC) layer will have clear or flexible design and eventually maintainable code.
Finally, note that database design and object (as in object-oriented) design are different things. The techniques used to arrive at are different and one should not assume object design based on database design.
Data Transfer Objects (DTOs) are obsolete. Their primary purpose was to allow appliations to interact with Enterprise JavaBeans before EJB version 3. Before Java Persistence Architecture (JPA) in EJB3, Entity EJBs (which map database tables) carries some EJB-specific freight that made them hard to use in non-EJB code such as the GUI interaction layer of a webapp. Thus, the DTO served the purpose of transporting table information from a POJO database object in the server-side GUI code to the EJBs in the persistence layer of the web application.
Since JPA Entity objects are themselves POJOs in JPA, there's no longer any need for a separate DTO.
Now in your case, you're home-brewing a persistence model doing it all with brute-force JDBC. But since you've already mapped the Entity (table) classes, you might find it easier and simpler in the long term to simply switch over to using JPA. JPA is available in 2 forms: basic JPA as implemented in systems like Hibernate and Apache OpenJPA, and EJB JPA, where you have the full power of the Enterprise JavaBean stack at your disposal. The advantage of using basic JPA is that it doesn't require an EJB container, so it can run in non-web applications (stand-alone apps) and in partial-stack webservers like Tomcat and jetty that don't implement EJB.
The beauty of using an Object Relational Management (ORM) system such as JPA is that you don't have to worry as much about the SQL. You can create a "working set" of Entity objects related to each other, manipulate them in the GUI layer, pass them to the business layer, then in turn to the persistence layer, which can commit them to the database in a single transaction.
There is a certain learning curve to doing this, but it's a very marketable skill, especially if you can combine it with an object management framework such as the Spring Framework, which can deal with low-level "grunt work" for you.
An IDE is no substitute for an Intelligent Developer.
Talk sense to a fool and he calls you foolish. -Euripides A foolish tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database