I have been writing a database-centric Java Swing application for a while.
The GUI and DAO-code ends up in a big tree like:
JFrame
|
JTabbedPane
|
+--------------------+----------------------+-------------+
| | | |
JPanel1 JPanel2 JPanel3 JPanel4
| | | |
JButtons--JTable1 JTextFields--JButton JTable2 JDialog--JTable3
i! i! i! i!
Model1 Model2 Model3 Model4
| | | |
+------------+-----------+---------+-------------------+
|
DataAccessObject
The application has several views, some contains a JTable for showing data, and some contain a dialog with a form for editing or adding data.
I have a DataAccessObject
with JDBC-connection. I use several models (extends AbstractTableModel
) to connect the views (forms or tables) with the DAO.
In my first version I implemented the DAO as a Singleton, then I learned that this is an anti-pattern and used Dependency Injection instead, so I basically initialize the DAO first and then inject it to the constructor of all the models. Then I initialize the JFrame and inject a reference to the models in the constructor in the hole GUI-tree.
Passing the reference to the models through the hole GUI tree feels very clumsy, but I know that I have good control of dependencies. But is there any better design I could use for a database-centric Java Swing applications with many views of data that needs a model with a connection to the database?
I would also support Shakedown's comment. It is all about layers. Separate your code into layers/tiers.
Since you were talking about Dependency Injection I would suggest you to take a look at Spring Rich Client framework to get a feel about how good Swing applications can be designed/developed.