Choix version Java SE + APIs Swing

Bonjour, voilà je voudrais lancer un mini-débat concernant les versions Java Se 5.0 et 6.0 ainsi que sur les différentes APIS Swing.

Je dois réaliser un projet avec une interface graphique importante ainsi qu'une grosse base de données derrière. Je me suis tourné vers une architecture 3-tiers avec l'utilisation du design pattern M-VC pour l'interfaçage graphique ainsi que du design pattern DAO au niveau de la liaison entre la couche métier et la couche BDD avec l'utilisation d'Hibernate pour obtenir une persistance des objets mais surtout une grand modularité au niveau du type de base de données, de passer facilement d'une base de données à l'autre, ie passer de MySQL à Oracle sans rien changer aux requêtes mais juste modifier le fichier properties d'Hibernate.

Au niveau de l'interfaçage prahique, je compte utiliser Swing que j'ai préféré à SWT. Sans rentrer dans un débat SWt/Swing, j'ai choisi Swing car SWT est natif et cela risque d'être gênant des fois suivant la plate-forme mais aussi parce que SWT n'est pas encore aussi bien fourni comparé à l'API Swing.

Je travaille actuellement sur un Windows SP2 avec Eclipse 3.2.1 et Java SE 5.0 update 10. Pour me simplifier la conception des IHM, je comptais me tourner vers un GUI qui serait un plug-in d'Eclipse. J'ai donc testé VE (Visual Editor) et Jigloo mais pour des raisons de licence, mon choix se tournait vers VE.

Mais je me pose de plus en plus de questions. La première est : quelle version de Java SE choisir? la 5.0 ou la 6.0? En effet, depuis que je reparcoure le forum, je me rends compte que la version 6.0 intègre pas mal de nouvelles API en standard du type JDIC, JxTable, etc...

Donc je me demande si mon intérêt ne serait pas d'avant de commencer à programmer de faire cette migration.

Pour Java 5.0 SE, j'ai d'abord l'habitude de l'utiliser et je ne dirais pas que je le maîtrise loin de là mais je m'en sors. Le problème vient essentiellement du fait qu'il faut rajouter pas mal de librairies supplémentaires poura arirver à ce que l'on veut.

Pour Java 6.0 SE, ce qui me fait un peur c'est sa jeunesse. En effet, la sortie officielle ne date que de décembre 2006 me semble et j'ai peur qu'il reste encore pas mal de bugs et que cela ralentisse mon développement. Mais bon, je me dis aussi que d'un autre côté, il faudra s'y mettre un jour ou tout du moins faire une migration mais surtout il intègre pas mal d'API en standard.

Donc voilà le premier point du débat : quelle version me conseillez-vous pour le développement?

Enfin, venons-en au dernier point, le choix des librairies. A la base, je comptais utiliser VE mais au fil des sujets, je me suis intéresséentre autre à l'API JForm. Du coup, l'utilité de VE diminue voire disparaît si je conçois mes formulaires avec JForm.

Donc je vous propose par l'intermédiaire de ce sujet, de donner votre avis sur les différentes librairies Swing qui peuvent être utiles. J'ai consulté évidemment le lien concernant les meilleures API graphiques sur le site APIs graphiques Java mais j'attendais surtout ici votre avis et votre opinion sur leur utilisation.

Voilà je vous remercie d'avance d'avoir pris le temps de lire et j'espère de répondre.

Salut,

A priori, je dirais que pour une application client lourd, il vaut mieux que tu te lances avec Java 6.

Bien que ce soit une technologie récemment promu "officielle", il y a assez longtemps qu'elle est en phase de test. La release parait stable, et je ne pense pas que tu rencontres de gros problèmes.

Ils conseillent un développement avec Netbeans 5.5 chez Sun. Il prend en charge Java 6, et de plus, pour ton projet en SWING, Netbeans comprend un éditeur graphique du plus haut niveau en la matière de Matisse.

En ce qui concerne ta base de données, ton choix d'Hibernate me parait pertinent dans la mesure où il te permet de changer de base de données si le besoin se ressent, en changeant de Dialect; Cependant, attention à bien définir tes classes et le lazy loading, afin d'obtenir les performances maximales, pour ma part j'ai toujours une petite appréhension à l'utilisation d'hibernate quand mon soucis est l'optimisation de l'application, car malgré les avantages qu'une telle api fourni, tu gardes peu de contrôle sur ce qui est vraiment fait au niveau des requêtes.

J'ai pour ma part préféré choisir un mappeur comme Ibatis, qui laisse plus le choix au développeur au niveau des requêtes. J'étais parti sur un projet par une analyse objet, puis une génération de la base via Hibernate, mais je me suis rendu compte qu'il y subsistait quelques problèmes d'optimisation, et du coup, je suis parti à l'envers : j'ai gardé mon modèle objet, j'ai crée mon propre modèle conceptuel optimisé comme je l'entendais, et j'ai fais les mappings objets/relationnels avec Ibatis. Du coup j'ai profité à la fois de mon modèle objet comme je le souhaitais, et j'ai pu tunné mes requêtes comme je l'entendais également. La gestion du cache sur Ibatis est également facile à mettre en oeuvre.

As-tu envisagé d'utiliser un framework comme Spring ? Ca pourrait grandement aider ton développement également.

A+

Au fait, sans vouloir entrer dans une polémique, je pense que SWT est un bon choix.

Le coté natif n'est pas un soucis, il suffit de voir comment eclipse tourne sur tous les environnements pour avoir une preuve de la stabilité de la librairie.

Il y a un grand gain en performance selon moi à utiliser SWT.

Essaie de voir si ton choix sur SWING est le bon, peut-être que SWT sera plus rapide et réactif..

A+

Citation:

---

Envoyé par KiLVaiDeN

As-tu envisagé d'utiliser un framework comme Spring ? Ca pourrait grandement aider ton développement également.

---

+1

Notamment pour l'intégration transparente d'Hibernate derrière ton DAO, ainsi que pour le respect strict de MVC avec Swing (et un minimum d'impact si changement SWT ou autre par la suite).

;)

Tout d'abord merci pour vos réponses.

Ayant débuté avec JCreator puis étant passé sous Eclipse peu de temps après, il est vrai que j'ai du mal à m'en défaire peut-être à tort. Donc c'est vrai que changer d'EDI me ne tente pas trop mais s'il faut passer à NetBeans pour me simplifier la tâche.

En ce qui concerne le choix Hibernate vs Ibatis par exemple, je ne sais pas trop en fait :? . Idéalement, voilà ce que je voulais : créer ma base de données moi-même à la main et ensuite utiliser Hibernate pour faire le mapping. Peut-être je prends le problème à l'envers mais c'est dans ce sens que ça m'intéressait pour des raisons de simplicité car je ne maîtrise pas du tout Hibernate et générer ma base à partir de mes classes, j'ai peur de mélanger les notions d'objet et de données.

Ensuite, pour le framework, oui je m'étais renseigné et documenté sur Struts ou encore Spring mais je ne sais pas pourquoi dans ma tête ça s'est bloqué à : framework = J2EE 8O

Je sais ça peut paraître bête mais c'est vrai que si j'arrive à franchier cette barrière spirituelle :roll: alors je pourrais m'orienter vers un projet J2SE avec utilisation du framework Spring notamment la gestion du MVC moi je dis pourquoi pas :lol: et l'intégration "facile?" d'Hibernate.

Donc vous me conseilleriez de m'orienter vers un développement J2SE 6.0 avec framework Spring sous NetBeans 5.5 ?

Enfin, le choix SWT/Swing je savais qu'on allait en reparler ;)

Pour SWT et ne m'étant pas non plus énormément documenté, le principal aspect qui m'a fait pencher du côté Swing c'est l'exhaustivité de l'API Swing par rapport à celle de SWT. Vous allez alors me demander que dois-je faire avec Swing que SWT ne saurait pas faire? Je vous répondrais que je ne sais pas et que c'est pour ça que j'ai besoin de vos lumières :) C'est vrai que l'aspect performance est très attractif mais à quel détriment? :?

Il me semble que le débat java 5 vs Java 6 est surtout à mettre en rapport avec l'historique d'une appli.

Si c'est une appli neuve, je ne vois vraiment pas pourquoi il faudrait discuter entre 5 et 6 : il faut choisir 6, à moins de ne pas avoir confiance dans le développement de java, et donc il faut choisir un autre environnement que java tout court.

Si c'est une appli déjà existante, avec des clients et des utilisateurs, la situation est plus difficile : peuvent-ils/veulent-ils passer à java 6 ?

Pour ce qui concerne les frameworks divers et variés, mon approche est qu'il faut vraiment se poser la question de savoir à quoi ils vont servir. La réponse habituelle est Si je change un jour ma base de données ce sera plus pratique ! ou alors : Ce sera plus générique !

Pour moi, ce genre d'argument est insuffisant ; il faut vraiment le mettre en rapport avec un usage. Ex : Un de tes utilisateurs ou client va-t-il changer de base ?... Divers clients utiliser des bases différentes ?... Si oui, alors cela risque de vouloir dire bien autre chose pour ton appli qu'une simple réflexion sur un framework, et, la plupart du temps (99,99% des fois) la meilleure solution est de dire : On prend une seule base, et on fera des interfaces d'import / export. Plus bourrin, mais autrement plus simple et efficace.

Donc, pour répondre à ta question sur les frameworks : pour quel usage ?

En effet, vu sous cet angle l'aspect framework n'a pas un réel usage tout du moins point de vue utilisabilité. En ce qui concerne les histoires des bases différentes, c'est un problème qui peut arriver chez les utilisateurs mais aussi en interne. En effet, il me faudrait une base Oracle pour supporter les nombreuses données quotidiennes que je vais sauvegarder. N'ayant pas encore acheté de licence ni choisi le SGBDR encore, je pensais développer sous HSQL en attendant de bien choisir la base de données définitive. C'est à ce niveau-là que j'ai choisi Hibernate.

Pour le framework en lui-même, je ne sais pas trop quoi en penser. Le logiciel que je dois développer va devenir la clé de voûte de solutions que la société proposera par la suite. Les prochaines applications seront des plug-ins du logiciel ou alors des variantes. Le côté framework m'intéressait plus pour cela que pour la gestion du changement possible de BDD.

Il est possible aussi que je passe complètement à côté de la notion de framework et que je confonde finalement.

Citation:

---

Envoyé par sironimo

Salut, je pense avoir à rencontrer le même problème. Je dois développer une application avec une base de données assez conséquante.

En effet, il s'agit d'une base de données médicales avec donc un enregistrement par minute et par client pour analyser sa situation physique. Cela représente donc 1440 enregistrements par jour et par patient.

ps : pour ma part, je stocke des relevés cliniques donc pas mal de valeurs à virgules.

---

Voici le type de données que je vais devoir gérer.

Honnêtement, je sais plus trop quoi penser du framework et de son utilisation :?

Citation:

---

Envoyé par sironimo

En effet, vu sous cet angle l'aspect framework n'a pas un réel usage tout du moins point de vue utilisabilité. En ce qui concerne les histoires des bases différentes, c'est un problème qui peut arriver chez les utilisateurs mais aussi en interne. En effet, il me faudrait une base Oracle pour supporter les nombreuses données quotidiennes que je vais sauvegarder. N'ayant pas encore acheté de licence ni choisi le SGBDR encore, je pensais développer sous HSQL en attendant de bien choisir la base de données définitive. C'est à ce niveau-là que j'ai choisi Hibernate.

---

Es-tu sûr ?... Pourquoi MySQL n'y suffirait pas ? (et encore pire, voir plus bas).

Chez les utilisateurs, qu'est-ce qui peut justifier que, pour votre produit, il soit nécessaire d'utiliser une autre base que celle de votre produit ? Si vous choisissez la base Toto, que l'utilisateur préfère Tata, pourquoi ?

Citation:

---

Envoyé par sironimo

Pour le framework en lui-même, je ne sais pas trop quoi en penser. Le logiciel que je dois développer va devenir la clé de voûte de solutions que la société proposera par la suite. Les prochaines applications seront des plug-ins du logiciel ou alors des variantes. Le côté framework m'intéressait plus pour cela que pour la gestion du changement possible de BDD.

Il est possible aussi que je passe complètement à côté de la notion de framework et que je confonde finalement.

---

Non non, c'est une question importante. Ce que je critique, c'est que quand on a répondu Hibernate Spring MVC à la question des frameworks, on est content.

Le premier framework qui apparaisse à te lire, c'est celui des plugins. En ce domaine celui qui semble avoir le vent en poupe est OSGi (wikipedia). En plus, comme c'est le système utilisé par Eclipse, cela devrait plaire à ton service commercial et te donner plein d'autres pistes. Mon avis est que tu ferais mieux de te préoccuper de ça plutôt que des finesses entre Java 5 et 6.0.

Au niveau des données que tu gères, de type médical, donc, tu ne les caractérises au niveau de leur gestion que par le terme d'enregistrement. La méthode la plus efficace pour faire des enregistrements est celle du fichier texte, avec un enregistrement par ligne. On est loin d'Oracle :D

... mais peut être y a-t-il d'autres choses au niveau de la gestion des enregistrements ?...

Citation:

---

Envoyé par spekal

Es-tu sûr ?... Pourquoi MySQL n'y suffirait pas ? (et encore pire, voir plus bas).

Chez les utilisateurs, qu'est-ce qui peut justifier que, pour votre produit, il soit nécessaire d'utiliser une autre base que celle de votre produit ? Si vous choisissez la base Toto, que l'utilisateur préfère Tata, pourquoi ?

---

tout d'abord, le produit s'adresse à des pharmaciens qui auront surement un SGBDR existant pour gérer les informations sur le patient. Le but est de venir se greffer à leur existant en évitant de leur revendre une autre licence.

Citation:

---

Envoyé par spekal

Non non, c'est une question importante. Ce que je critique, c'est que quand on a répondu Hibernate Spring MVC à la question des frameworks, on est content.

Le premier framework qui apparaisse à te lire, c'est celui des plugins. En ce domaine celui qui semble avoir le vent en poupe est OSGi (wikipedia). En plus, comme c'est le système utilisé par Eclipse, cela devrait plaire à ton service commercial et te donner plein d'autres pistes. Mon avis est que tu ferais mieux de te préoccuper de ça plutôt que des finesses entre Java 5 et 6.0.

---

Je dois dire que je suis assez perdu entre plugin et framework. La vraie question est donc de déterminer l'EDI mais aussi les différents plug-ins. De ce que j'ai pu lire sur OSGI, il est surtout utiliser pour l'internet et l'intranet hors ici mon application sera locale. Donc finalement qu'est ce qu'un framework et en ai-je vraiment l'utilité??

Citation:

---

Envoyé par spekal

Au niveau des données que tu gères, de type médical, donc, tu ne les caractérises au niveau de leur gestion que par le terme d'enregistrement. La méthode la plus efficace pour faire des enregistrements est celle du fichier texte, avec un enregistrement par ligne. On est loin d'Oracle :D

... mais peut être y a-t-il d'autres choses au niveau de la gestion des enregistrements ?...

---

Déjà si le client a déjà un SGBDR, cela me paraît important. Mais de façon plus générale pourquoi passer par Oracle plutôt que des fichiers ? Déjà, il faudrait savoir s'il y a gain de temps entre lecture sur un fichier et dans une base. Ensuite, le problème de taille ne sera que partiellement résolu. Que tu reçoives 1440 données par jour et que tu les stockes dans une BDD ou dans un fichier, au final ça chiffera. Les enregistrements me servent essentiellement à dessiner des courbes. De plus, si je stocke ces informations dans un fichier, certains champs devront être cryptés comme par exemple le numéro de sécurité sociale et autres informations puisqu'il s'agit de données personnelles et médicales.


Bref j'ai l'impression que je patauge de plus en plus à définir la stratégie à employer pour que mon application soit la plus robuste possible mais aussi modifiable.

Je suis un peu perdu. En ce qui concerne la BDD, j'en ai évident besoin pour pouvoir récupérer mes données plus facilement, rechercher grâce aux clés et surtout m'éviter des parcours dans le fichier, parcours qui pourrait prendre du temps.

Donc finalement, je m'interroge sur le choix ou non d'un framework. Que m'apporterait-il dans mon cas ?

En ce qui concerne SWT/Swing, je pense pour l'instant le faire en Swing et qui sait le reprendre en SWT plus tard.

Le développement se ferait avec java SE 6.0 et j'hésite toujours à utiliser NetBeans 5.5 + Matisse car même s'il était moins complet, Eclipse + VE je pense pouvait suffire.

Donc le débat sur la version du Java SE est inintéressant, il ne prend son sens que si je devais reprendre une appli développée en 5.0.

Enfin, le débat s'orienterait donc vers le choix ou non d'un framework ainsi que de l'EDI à choisir apparemment eclipse vs NetBeans.

Par contre, en ce qui concerne Hibernate et Ibatis, d'autres personnes ont un avis sur le sujet?

J'ai developpé il y a quelques temps, une application de gestion.
J'ai utilisé Netbeans. J'ai ainsi pu réaliser les écrans très rapidement.
J'ai utilisé Mysql pour la partie base de données ainsi qu'Hibernate pour la partie persistance. Je suis parti d'un modèle objet et j'ai ensuite généré
le schéma de la base de données.
Enfin, j'ai utilisé Spring pour la gestion transactionnelle et l'injection de dépendances, notamment de la session Hibernate dans mes DAO.
L'application n'est sans doute pas parfaite, mais je la trouve assez bien séparée en couches. Il serait ainsi possible de récupérer une bonne partie du code pour la faire évoluer en application web par exemple.

Evidemment, j'aurais pu ne pas utiliser Spring et Hibernate et tout faire en JDBC pur, cependant, je pense que les services offerts par ces frameworks sont très intéressants.

Moi je crois que au niveau où tu en es il faut se concentrer sur les fonctions de l'appli, de façon à ce qu'elles correspondent à ce que veulent les pharmaciens (et d'autres).

Cela signifie désigner qui est utilisateur pour toi : le pharmacien bien sûr, mais tu peux considérer que le service commercial de ta boîte est un utilisateur, que ceux qui vont écrire des plug-in seront utilisateurs, etc. C'est à partir de cette somme d'usage que tu vas trouver des personnes avec qui discuter, et qui en tous cas t'aideront à faire tes choix.

Bien sûr que Hibernate et autres sont intéressant, mais ils ne te diront rien de ce que tu dois faire.

Par exemple il n'y a pas longtemps j'ai fait un logiciel de caisse enregistreuse. Pareil que toi dans un autre domaine, et il fallait bien sûr prévoir des possibilités d'extension. Mais les ingénieurs de la boîte qui m'a commandé ça connaissaient parfaitement le SQL, et préféraient en rester là. Pour préparer les extensions, la seule chose qu'ils m'ont demandé est... un outil d'administration externe, pour intervenir directement sur la base en cas de pépin !

Donc, moi, plutôt que de réfléchir à la théorie des frameworks, bien sûr fort utile pour la culture générale et la pertinence des choix, je te conseille plutot au niveau où tu en es de réfléchir à qui sont tes utilisateurs, et de réfléchir à comment entrer en dialogue avec eux. C'est autrement plus difficile, mais autrement plus porteur. Pour faire mon logiciel de caisse enregistreuse, par exemple, j'ai demandé son avis à ma boulangère. (et à mon client).

Va voir des pharmaciens, va voir un commercial de ton service commercial, va voir ton chef, campe devant la machine à café, va voir... etc.

Bon je vais vous exposer la situation. Le logiciel que je développe existe depuis 1 an maintenant mais a été totalement baclé, aussi bien au niveau de la structure du code que la conception de la BDD et même au niveau IHM, bref c'est un bordel innomable :?

Du coup, le chef m'a dit : il faut reprendre ça de zéro. Donc pour lui, l'aspect structuration et architectural de l'application sont importants, ils ont déjà perdu un an sur ce développement, il préfère cette fois-ci ne pas se précipiter et prendre bien le temps de choisir.

Premier point, cela signifie que je connais déjà toutes les fonctionnalités de l'application, que je l'ai déjà vu tourné bref que je la connais bien donc j'ai une vue d'ensemble de ce que je dois faire. C'est quelquepart de la reprise de code enfin plutôt d'idée de code car ça a été très mal codé 8O

Pour tout ce qui est renseignement sur l'utilisateur, voire avec les commerciaux, ceci a déjà été fait. Une réunion est même prévue avec les commerciaux pour que l'on regarde ensemble l'aspect IHM mais ils ne peuvent intervenir sur la structure de l'appli elle-même.

De plus, je me trouve être le seul informaticien de la boîte. Sortant de mes études et n'ayant jamais eu d'expérience telle, ie le monopole du service informatique, je me dois d'apprendre vite et sur le tas. J'aurais bien aimé être sous un responsable informatique qui m'encadrerait mais là je suis livré à moi-même et c'est pour cela que je viens quérir vos avis.

Enfin, les pharmaciens, futurs utilisateurs, n'ont pas de service de développement derrière donc en fait c'est nous qui faisons tous les choix. Je n'ai pas comme toi à produire un logiciel pour un autre service informatique qui pourrait me guider mais directement à des pharmaciens qui sont loin d'être qualifiés dans le domaine et qui n'ont pas à l'être.

Voilà j'espère avoir été plus clair sur ma situation ;)

... donc l'informaticien précédent s'est fait virer au bout d'un an, après avoir tout de même fait la liste des fonctions, les avoir réalisées, et tout le monde affirmerait mordicus que c'est super baclé ?.... Mouais...

Un conseil : prudence. Vise d'abord ton prochain CV (pour dans un an). Donc, effectivement, regarde Hibernate, etc. Cela te servira toujours.

... mais peut être souhaiterais-tu réaliser un bon logiciel, au cours de l'année qui t'attend :D Voyons ça.

Cas 1 : les fonctions dans le logiciel existant sont à peu près complètes, et donnent relativement satisfaction aux pharmaciens. Il faut surtout arranger la structure interne.

En ce cas, considère ton prédécésseur comme ton maître. Faire ça en un an, c'est très bien. Aussi vise prioritairement, et sans vergogne aucune, ton prochain CV ; il t'arrivera probablement la même chose qu'à ton prédécesseur dans un an. En attendant, essaie tantôt Hibernate, tantôt Oracle, tantôt SAP, cela n'a aucune importance.


Cas 2 : le logiciel ne donne pas satisfaction aux pharmaciens, et la structure interne rend difficile les évolutions. Comme ton chef dit, il faut tout recommencer. Mais il y a un historique, des acteurs à différents niveaux, etc.

En ce cas, je te conseillerais de procéder par petits pas, en faisant des maquettes utilisables successives, que tu montreras aux différents intervenants qui sont avec toi tout au long du travail. Réfléchis d'abord aux notions de maquettes utilisables, qui progressent d'une version à l'autre, et aux relations que tu peux développer avec tes collègues et utilisateurs.

... et je ne te conseille toujours pas de frameworks ! :lol: En ce domaine, donnes-toi du temps, tu peux bien prendre 1 semaine à les regarder, les essayer, et surtout à voir si tu te sens à l'aise avec. Dis-toi bien que dans 6 mois tu devras te sortir de quelques-unes de tes bourdes, et que à ce moment là ce qui te sauveras c'est si tu as de l'estime pour la techno que tu emploies, et de bon rapports avec ceux qui l'utilisent et peuvent t'aider (liste de discussions, etc).

En une demi-journée tu peux faire le tour de 60% d'hibernate, une autre de Spring, etc ; avec tous les frameworks cela te fera 3/4 jours qui ne seront pas perdus, tu peux en être sûr.

Bonne chance.

Citation:

---

Envoyé par spekal

.
En une demi-journée tu peux faire le tour de 60% d'hibernate, une autre de Spring, etc ; avec tous les frameworks cela te fera 3/4 jours qui ne seront pas perdus, tu peux en être sûr.

---

Entièrement d'accord :ccool: !
Jette un coup d'oeil sur Les meilleures API Java ...

Java 1.6 + Spring + Hibernate :mrgreen: avec ca tu fais du propre

Perso je préfère Ibatis :) Plus simple, bonne gestion du cache, laisse plus de liberté sur le SQL utilisé..

Hibernate c'est une boite noire, j'aime pas trop le principe. Rien de mieux qu'un modèle de données maîtrisé par le développeur. Plus de travail, certes, mais quand on fait bien son travail, on peut mieux optimiser selon moi.

Mais on est pas là pour faire un débat sur la meilleure API de persistance !

A+

Merci pour vos conseils. Je pense qu'avant d'aller plus loin, je vais passer quelques journées à regarder un peu plus en détails Hibernate, Spring et autres frameworks avant de me décider. Comme vous l'avez dit, ce n'est pas du temps perdu.

Evidemment, je souhaite réaliser un bon logiciel durant l'année à venir, je suis homme qui relève les défis et qui se consacre à 100% au(x) projet(s) qu'il mène. C'est pour cela que je consacre autant de temps à concevoir au mieux la structure de l'application.

De toute manière, je vais me renseigner de mon côté et n'ayant malheureusement pas que ça à faire cette semaine, je me propose de vous tenir au courant de mes avancés et de mes différents choix pour peut être en rediscuter et être à même pour ma part de les justifier suite à une utilisation ;)

ps : je vais aussi regarder du côté d'Ibatis.

Je ne comprends pas les gens anti-framework.
Je suis bien d'accord sur le fait que ce n'est pas la peine d'en mettre partout
et de tous les utiliser, mais leur principe est quand même de ne pas réinventer la roue à chaque fois.
Hibernate et Spring ont fait leur preuve.
Si tu apprends Hibernate, ça te servira pour les EJB3, puisque Hibernate est
une implémentation de la couche de persistence des EJB3.
Certains concepts de Spring sont également repris dans les EJB3.

Après tu fais ce que tu veux, je ne veux pas mal te conseiller, car l'apprentissage de ces frameworks nécessitent quand même un investissement important. Quand quelqu'un a parlé d'une demie journée pour faire 60% du tour d'Hibernate, je pense ou j'espère qu'il parlait d'une vue de haut, car sa bonne utilisation et compréhension nécessite quand même un peu de pratique.

Ayant utilisé Hibernate dans plusieurs projets, je pense que le temps d'apprentissage pour quelqu'un qui maîtrise bien le modèle objet peut être rapide.

La documentation d'Hibernate est suffisamment claire pour pouvoir rapidement exploiter Hibernate et le configurer d'une façon efficace. En suivant le tutoriel de "présentation" de la documentation, on arrive très vite à faire quelque chose, une demi-journée ne me parait pas intenable.

Après, rendre l'application performante, bien gérer le cache, etc etc.. C'est une autre histoire ! Et c'est la raison qui m'a fait me tourner plutôt vers Ibatis dernièrement; C'est une usine à gaz Hibernate... Et tu dois mettre du lazy-loading partout pour bien faire.. Ca devient vite un cauchemar de configuration..

La même remarque est valable pour Spring.. Mais au moins Spring est vraiment utile et indispensable, car les classes deviennent limpides avec l'injection.

Je suis donc au final très satisfait du "couple" Spring-Ibatis car je garde la main sur mes requêtes et peux compter sur la puissance de SQL tout en ayant l'apport de l'injection par Spring. ( Sans parler de Spring MVC pour les applications internet car on parle ici de client lourd ).

Dernière remarque : Ibatis est bon à utiliser dans le cas où on sait quelle base de données on vise, car on peut alors utiliser tout le potentiel de la base de données. Pour faire une application générique, qui doit fonctionner sur plusieurs bases de données différentes, il est préférable d'utiliser Hibernate qui s'adapte avec sa notion de Dialect. Mais même là, rien ne t'empêche de faire plusieurs configuration d'Ibatis, un par base de données visée.. Et si tu utilises le SQL standard, tes requêtes devraient passer sur toutes les bases de données...

C'est une question de goût au final -> utilise ce qui te plaît le plus et ce que tu pense pouvoir maîtriser le plus. Sépare bien les couches pour qu'un jour tu aies la possibilité de changer facilement d'API si le besoin se ressent.

A+

Oui, c'est moi le quelqu'un, tu as raison, c'est 60% vu de haut.

Je ne voulais pas apparaître comme anti-framework, mais je voulais seulement recentrer le débat sur à quoi te sert ton appli. Certes, quand tu as appris Hibernate, ça sert pour EJB3... mais quand est-ce qu'on aborde les demandes client ?... on n'a toujours pas avancé d'une virgule dans ce domaine.

Et quand on démarre une appli, le plus important est le rapport que l'on va avoir avec clients et utilisateurs, ou commanditaires. Le reste, je maintiens, ça vient après. Si ça vient avant, Hibernate ou pas, l'appli est déjà bonne pour la poubelle. En effet, au risque de paraîre anti-framework, dans la majorité des cas, je pense que Hibernate ne sert absolument à rien.

Je ne maîtrise pas trop la notion d'injection : qu'est-ce que c'est finalement? Quels en sont les avantages ?

Par contre spekal, je ne comprends pas trop ce que tu entends par demande client désolé :oops: Je veux bien avancer sur le sujet ;)

Citation:

---

dans la majorité des cas, je pense que Hibernate ne sert absolument à rien.

---

Il sert à éviter d'ecrire du SQL dans ton application, de ne pas mélanger données objets et données relationnelles. Je trouve que c'est déjà beaucoup.
Je trouve ça quand même plus élégant et lisible de manipuler des getter et setter que de faire des select, insert, update pour la moindre opération.

Pour ce qui est de l'usine à gaz, je ne comprends pas vraiment.
En utilisant une configuration de base, tu auras déjà de bonnes performances.
Après si tu veux gérer un cache de second niveau et tout un tas de paramètres, tu le pourras et ce n'est pas plus compliqué que le reste.
En général les problèmes de performances viennent souvent de l'architecture de l'application et non pas de quelques paramètres à bidouiller, ce serait trop simple.

Pour ce qui est du lazy-loading, il n'y a rien à configurer, il est activé par défaut. Une fois qu'on a compris le principe, y a rien de sorcier.

Ibatis, est certainement très bien, je n'en doute pas, mais ce n'est pas la peine de démonter Hibernate avec de tels arguments .

Citation:

---

Envoyé par sironimo

Je ne maîtrise pas trop la notion d'injection : qu'est-ce que c'est finalement? Quels en sont les avantages ?

Par contre spekal, je ne comprends pas trop ce que tu entends par demande client désolé :oops: Je veux bien avancer sur le sujet ;)

---

Moi aussi, je suis intéressé de savoir ce qu'est l'injection, tout le monde en parle mais je n'ai pas bien compris. Est-ce que cela a un rapport avec le pattern IoC ?

Spring semble être divisé en plusieurs modules afin de n'utiliser ceux qui nous intéressent. Lesquels recommandez-vous pour un client lourd ?

Injection de dépendance (DI, Dependency Injection), et Inversion de Controle (IoC, Inversion of Control), sont deux choses différentes.

DI : Une classe ne se charge pas elle même de résoudre ses dépendances; Un élément externe, se charge, via des setteurs ou des constructeurs, "d'injecter" ces dépendances. Par exemple, classe A utilise classe B. Usuellement on a quelque part dans la classe A un "new B()" qui traine. Avec DI, rien de tout ça. La classe A possède un setB(), et un autre élément externe, se charge, à l'initialisation ou à la demande, d'appeller ce setB() avec un objet B.

IoC : Un peu pareil, la classe A veut récupérer pour un traitement un objet B. Elle va alors demander à un conteneur, de lui donner un B, et c'est ce conteneur qui saura quelle classe appeller et quelle classe fournir.

Voila, vite fait, beaucoup d'autres infos sur le net.

A+ :)

Salut,

Je ne sais pas si vous l'avez vu, mais cela pourrait vous intéresser : le premier prototype de la JSR-296 a été rendu publique : http://weblogs.java.net/blog/hansmul...ation_fra.html

Pour info il s'agit du Swing Application Framework qui devrait faciliter le développement d'application graphique !

Avec une petite présentation intéressante à lire : http://weblogs.java.net/blog/hansmul...ation_fra.html

a++

Pour un client lourd, tu peux utiliser l'injection de dépendances, par exemple pour la sessionFactory de tes Daos Hibernate.
Tu peux aussi utiliser la gestion des transactions.

Voilà ce que j'ai utlisé de Spring avec un client lourd.

Citation:

---

Envoyé par adiGuba

Je ne sais pas si vous l'avez vu, mais cela pourrait vous intéresser : le premier prototype de la JSR-296 a été rendu publique : http://weblogs.java.net/blog/hansmul...ation_fra.html

Pour info il s'agit du Swing Application Framework qui devrait faciliter le développement d'application graphique !

Avec une petite présentation intéressante à lire : http://weblogs.java.net/blog/hansmul...ation_fra.html

---

Ca a l'air super intéressant, je vais aller voir ça, merci pour les liens ;)

Merci pour ces explications :D

Je vais y jeter un oeil de plus près en espérant que l'apprentissage ne soit pas trop long. ;)