Discussion :

[n!co]

Bonjour,

Je dois re-concevoir une application en réutilisant la plateforme de Netbeans.
La version existante est composée de plusieurs modules (chacun ayant son exécutable). On a un module de gestion général, un module de saisie et un module de calcul. Chacun travail avec la même base de données et manipule donc des objets (pojo) communs.

Je débute avec le monde du RCP et je me demandais comment je pouvais modéliser mon appli, pour avoir qqs chose de facile a maintenir et d'évolutif ?

Pour détailler un peu plus l'architecture, l'appli est découpé en 2 parties : présentation, métier/persistance.
C'est une application full desktop, avec seulement la base de données qui est délocalisée sur un serveur. Mon code métier et mon code de présentation seront donc dans la plateforme !

Avec Netbeans, on peu allègrement utiliser la gestion des modules, il sera alors évident que chaque module de l'ancienne version aura son module sur la plateforme.
Mais je me posais les questions de comment pousser plus loin le concept :
Faut il que aussi je découpe mes différentes parties en modules ?
Faut il que je crée un module dédié pour mes POJO et fichiers de mapping ?

Merci de votre expérience dans ce domaine

[vbrabant]

Alors, oui. Le mieux est de dissocier la couche présentation de la couche métier. Et donc d'avoir des modules bien séparés pour cela.

Avec NetBeans, il faudra dire que ton(tes) module(s) de présentation dépend(ent) de ton(tes) module(s) "metier".

Et oui, le mieux est de créer un module séparé qui contiendra tes POJOs et d'indiquer que les autres modules dépendent de celui-là.

Je pense que c'est la meilleure façon de travailler. En tout cas, c'est comme cela que je le ferais, si c'était à moi de le faire. D'ailleurs, au travail, nous travaillons de cette façon modulaire, où nous retrouvons presque un JAR pour chaque type de travail bien précis. Toi, tu auras un nbm pour chaque module.

Aussi, NetBeans demande à ce que les 3rd party jar soient également enveloppés dans des nbm. Par exemple, si tu utilises commons-io de jakarta, et JFreechart, tu peux les mettre tous les deux dans le même nbm, ou chacun séparément. Le mieux est d'avoir un nbm par 3rd party jar. Ca demande un peu plus de travail, mais ca permet de mieux gérer les dépendances entre les modules. Et de ne charger que les modules qui sont nécessaires.

Bonne chance.

P.S. Si tu pouvais partager avec nous tes impressions sur le RCP de NetBeans, ou même écrire un (court) article à ce sujet, ce serait vraiment super.

Vincent

[n!co]

Sympa pour cette réponse rapide.
Tu me reconfortes dans mon idée de départ, j'ai plus qu'a me lancer

Ca tombe bien que tu me lances sur les 3rd party jar, je me posais une question a ce sujet.
J'avais bien compris que chaque jar tiers devait être "encapsulé" dans un nbm distinct (merci au bon tuto sur le site de netbeans)
Mais alors que je créer un nbm pour hibernate, je me demandais s'il je devais vraiment créer un nbm pour chaque dépendance ou si fallait mieux juste les rajouter au classpath.

Je pense qu'un nbm est quand même mieux, ca facilite le déploiement des mises a jour, bien que la démarche est un peu lourde a mettre en place, en déclarant toutes les dépendances de modules partout (netbeans 5.5 ayant un "tout petit peu" simplifier la méthode).

Encore merci pour tous ces compléments d'information.

PS : Je ferais volontier un petit article sur Netbeans Platform quand j'aurais un peu plus de recule (et quans son adoption sera validé)

[divxdede]

Il est facile d'inclure les librairies tierces en créant des "Library Wrapper Module".
Tout tes modules (les tient + les tierces) tu les ajoutes au sein de ce qu'on pourrait appeler un projet d'application "Project Suite Module".

Le découpage par module (présentation / metier) et une bonne chose et permet de mieux structurer ton code.

Les "Library Wrapper Module" sont facile a créér mais peuvent poser quelques soucis:

1. Quand tes librairies ont des dll et autres bibliothèques natives, je ne sais pas trop comment faire.
2. Mettre à jour une "Library Wrapper Module" n'est pas super-aisé.

Mais l'architecture des modules de Netbeans est bien fichue.

[n!co]

Salut divxdede,

Merci de m'avoir corrigé, c'est bien des wrapper dont je parlais et non de simple nbm. L'inconvénient des wrapper vis a vis du classpath, c'est de devoir déclarer toutes les dépendances entres le module.

Exemple, j'ai mon module métier qui intégre le gestionnaire de persistance Hibernate et pour simplifier son utilisation, je vais utiliser Spring.
il faut alors créer deux wrappers sur les bibliothèque d'Hibernate et de Spring, et signaler la dépendance de mon objet métier sur ces deux warppers. Maintenant, le package ORM de Spring utilise le package Hibernate lui aussi, il alors déclarer une nouvelle dépendance.
Imaginez maintenant le bronx quand on va utiliser des bibliothèques style log4j qui vont avoir des dépendances de partout

Maintenant ce petit désagrément est largement compensé par les avantages qu'offrent les wrappers au niveau de la sécurité et la décision faite lors du chagrment de la bibliothèque associée.

Sinon la mise a jour ne sait pas comme un nbm vu que structurellement c'est quasiment la même chose ?
Je vais chercher plus d'info la dessus.

En tout cas, le projet a été validé, je vais donc pouvoir le lancer sur la dev de la plateforme

[divxdede]

L'avantage de l'enrobage fait par le Library Wrapper Module et de pouvoir attacher une "signature" au module.

Ainsi Netbeans sera capable de creer le déploiement JavaWebStart correctement "signé" pour être déployable sur le web sans intervention majeur de la part du développeur.