Comment une application Java Swing base de données centrée sur être conçu?
-
01-10-2019 - |
Question
Je suis en train d'écrire une base de données centrée sur les applications Java Swing pendant un certain temps.
L'interface graphique et se termine le code DAO-up dans un grand arbre comme:
JFrame
|
JTabbedPane
|
+--------------------+----------------------+-------------+
| | | |
JPanel1 JPanel2 JPanel3 JPanel4
| | | |
JButtons--JTable1 JTextFields--JButton JTable2 JDialog--JTable3
i! i! i! i!
Model1 Model2 Model3 Model4
| | | |
+------------+-----------+---------+-------------------+
|
DataAccessObject
L'application dispose de plusieurs points de vue, certains contient une JTable pour montrer des données, et certains contiennent une boîte de dialogue avec un formulaire pour modifier ou ajouter des données.
J'ai un DataAccessObject
avec JDBC connexion. J'utilise plusieurs modèles (étend AbstractTableModel
) pour relier les vues (formulaires ou tableaux) avec le DAO.
Dans ma première version que je mis en œuvre le DAO comme Singleton, alors j'appris que c'est un anti-modèle et utilisé l'injection de dépendances à la place, donc j'initialiser essentiellement le DAO d'abord, puis l'injecter au constructeur de tous les modèles. Ensuite, j'initialiser le JFrame et introduire une référence aux modèles dans le constructeur dans le trou GUI-arbre.
En passant la référence aux modèles à travers l'arbre GUI trou se sent très maladroit, mais je sais que j'ai un bon contrôle des dépendances. Mais est-il une meilleure conception que je pourrais utiliser pour une base de données Java centrée sur les applications Swing avec de nombreuses vues de données qui a besoin d'un modèle avec une connexion à la base de données?
La solution
J'appuie également le commentaire de Shakedown. Il est tout au sujet des couches. Séparez votre code en couches / niveaux.
Puisque vous parlez de l'injection de dépendances, je vous suggère de jeter un oeil au framework Spring Rich Client pour avoir une idée sur la façon dont bon swing applications peuvent être conçues / développées.