Erf, c'est bien ce que je pensais...Envoyé par bassim
J'ai fait mes tests directement dans le code pour la partie import et j'ai pas ajouté la partie graphique.
Je suis vraiment un
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Erf, c'est bien ce que je pensais...
J'ai fait mes tests directement dans le code pour la partie import et j'ai pas ajouté la partie graphique.
Je suis vraiment un
J'ai passé un bon moment sur JTheque aujourd'hui et en fait, il y a encore beaucoup plus de bugs et d'instabilité que je pensais...
La version beta 1 était un peu prematuré
Je vais travailler à corriger tout ça et à implémenter les fonctions manquantes.
Si vous avez encore des commentaires, n'hésitez pas
j'aimerais bien voir comment t'as architecturé (ça existe !?) ton application !
L'architecture actuelle n'est pas encore parfaite, mais au niveau globale, j'utilise MVC pour séparer les différentes couches de l'application.
Ensuite, dans la partie Swing, j'ai séparé la partie action de la partie affichage le plus possible.
Pour la partie persistance, j'ai pas mal abstrait la gestion. J'ai des Dao ainsi que des EM (Entity Manager) et chacun de mes objets (Film) a une implémentation concrète (FilmImpl) ou sont localisés les opérations métiers et une partie abstraite (Film) pour la gestion pure des données.
Après, je sais pas trop comment te répondre précisement, les parties sont
chacune assez bien séparé et architecturée spécifiquement.
Mais c'est vrai qu'il y a encore un peu de border
Tu aimerais d'autres infos ?
ton architecture ressemble plus à une architecture 3-Tiers qui encapsule MVC dans la partie Présentation que du MVC purL'architecture actuelle n'est pas encore parfaite, mais au niveau globale, j'utilise MVC pour séparer les différentes couches de l'application.
Ensuite, dans la partie Swing, j'ai séparé la partie action de la partie affichage le plus possible.
Pour la partie persistance, j'ai pas mal abstrait la gestion. J'ai des Dao ainsi que des EM (Entity Manager) et chacun de mes objets (Film) a une implémentation concrète (FilmImpl) ou sont localisés les opérations métiers et une partie abstraite (Film) pour la gestion pure des données.
Après, je sais pas trop comment te répondre précisement, les parties sont
chacune assez bien séparé et architecturée spécifiquement.
Mais c'est vrai qu'il y a encore un peu de border
Tu aimerais d'autres infos ?
tu utilises JDBC/SQL pour l'accés à la BDD ?
Oui, j'utilise JDBC pour la partie persistance, mais je comte passer à JPA quand j'aurai le temps.
En fait, c'est quand même du MVC, mais j'ai presque un MVC pour la vue également. Après, la partie modèle de mon MVC, j'ai repris des concepts d'application 3-tiers que je trouvais bien.
Je dirais qu'avec JPA (que je suis entrain d'apprendre) on s'abstrait du modèle relationnel, une conception objet suffit !
Je comprends pas vraiment ce que tu veux dire...
Si tu entends par là qu'on est plus dépendant du modèle relationnel de la base de données, c'est exact, mais sinon, ben précises
Je prends exemple sur une application que j'ai faite (permet de faire le suivi des enseignements LMD):Je comprends pas vraiment ce que tu veux dire...
Si tu entends par là qu'on est plus dépendant du modèle relationnel de la base de données, c'est exact, mais sinon, ben précises
après avoir crée les diagrammes de classes et les avoir transcrit en code, j'avais pas envie de faire une autre étude pour créer ma BDD (MCD, MLD)
C'est la qu'intervient JPA ou Hibernate ou autre qui permet de créer le shéma de ma BDD à partir de mon modèle objet !
Oui, c'est juste
J'avais compris ça, mais c'est vrai que c'est un avantage. Par contre, j'ai travaillé un moment au boulot sur un très gros projet avec d'énormes volumes de données et même si on générait la base avec Hibernate, on devait faire du tuning ensuite sur la base pour améliorer les performances et on avait un DBA qui bossait dessus.
Mais c'est vrai que pour de petits projets, tu n'as pas besoin de t'ocupper de créer la base
Tuning, càd ?Oui, c'est juste
J'avais compris ça, mais c'est vrai que c'est un avantage. Par contre, j'ai travaillé un moment au boulot sur un très gros projet avec d'énormes volumes de données et même si on générait la base avec Hibernate, on devait faire du tuning ensuite sur la base pour améliorer les performances et on avait un DBA qui bossait dessus.
Mais c'est vrai que pour de petits projets, tu n'as pas besoin de t'ocupper de créer la base
Tuning <=> placer des indexes au niveau des colonnes afin que le SGBD puissse localiser plus vite telle ou telle colonne, n'attaquer les tables quye selon des indexs définis dans le requêtes, ne pas utiliser certains types d'ordres SQL les que les sous requêtes, par exemple: in/not in, utilisation de group by et d'agregats ...
Enfin plein de choses dans ce style qui font que tes requêtes boostent au lieu de se trainer lamentablement.
Exactement
Pour ceux qui ont utilisé JTheque ou qui ont vu l'interface ou encore qui ont vu à quoi ressemblait ExtendedFrame, vous pensez quoi des fenêtres ?
Personnellement, autant au début, je trouvais ça joli, autant maintenant je trouve ça lourd et moche
Quand je vois les fenêtres Vista ou Mac OS, je me dis que c'est bête de tout gacher avec des fenêtres comme ça juste pour pouvoir être plus souple...
J'hésite à repasser aux fenêtres de Java qui sont plus jolies et surtout qui ne font pas tâche sur l'OS.
Qu'en dites-vous ?
Très en faveur perso, et çà te fera quelquechose de moins à maintenir
Mais je comptais pas arrêter de maintenir ExtendedFrame, je comptais ajouter un deuxième type de fenêtre qui puisse aussi utiliser les glasspane. Ca fera une fenêtre simple d'utilisation.Très en faveur perso, et çà te fera quelquechose de moins à maintenir
Mais c'est vrai que j'hésite entre ça ou me développer ma petite classe extends JFrame propre à JTheque
A la limite je n'hériterais même pas de JFrame mais utiliserais une contrôleur possédant une référence sur une JFrame. Ensuite le contrôleur permttra de contrôler (non mais sans blague ^^) certains aspects de la JFrame comme la modification du glasspane au moyen d'accesseurs (un petit singleton avec la JFrame principale de ton appli, voire l'unique JFrame, en tant qu'attribut et l'affaire est jouée)
C'est pas bête non plus comme technique
Il y aura en effet certainement plus qu'une JFrame et des JDialog si je n'utilise plus ExtendedFrame.
Je verrai comme je ferai quand j'aurai décidé, je vais d'abord me consacrer aux derniers problèmes qu'il reste encore dans la bêta et je verrai ensuite
Partager