Discussion :

[bruno782]

Bonjour,

ayant une appli web de gestion de congés à développer (consultation, saisie, gestion de groupes, notion de roles etc..), je me pose la question de savoir si je dois la développer en utilisant un simple java+servlet+jdbc ou alors sortir le grand jeu ejb and co... quels sont les avantages et inconvénients de chacun de ce choix..

Cette interface servira dans le cadre d'une entreprise est devrait pouvoir être utilisable par 200/300 personnes...

Merci pour vos avis

[menuge]

Utilise J2EE avec Eclipse... c'est ce qu'il y a de mieux pour ce genre de chose

[zegreg]

Bonjour,

ayant une appli web de gestion de congés à développer (consultation, saisie, gestion de groupes, notion de roles etc..), je me pose la question de savoir si je dois la développer en utilisant un simple java+servlet+jdbc ou alors sortir le grand jeu ejb and co... quels sont les avantages et inconvénients de chacun de ce choix..

Cette interface servira dans le cadre d'une entreprise est devrait pouvoir être utilisable par 200/300 personnes...

Merci pour vos avis

Personellement je dirait qu'au point de vue architecture c'est toujours mieux de sortir la logique business de tes servlets (et certainement des jsp) dans des ejb.

Maintentant il faut savoir de combien de temps tu disposes pour le developpement et voir aussi les évolutions éventuelles de ton appli. Egalement voir combien de personnes se connecterons en meme temps sur l'appli (je suis pas sur que 300 pers se connecterons en meme tps pour introduire des congés)

[ego]

Tu peux rester simple avec Java/servlet/JSP.
Comme tu auras besoin de transactions avec la BD, je te conseille d'utiliser SPRING qui te permettra de rendre les opérations de tes classes Java transactionnelles.
Pour la montée en charge (200/300 personnes), tu pourras soit mettre une grosse machine soit un cluster de Tomcat

[bruno782]

Merci pour vos réponses.. et pensez-vous que d'autres technologies peuvent mieux répondre à cette problématique que java?

[viena]

Tu peux tres bien partir sur une solution J2EE sans EJB. Les EJB ont leurs avantages et leurs contraintes...
Quoi qu'il en soit, quand on ne connait pas trop J2EE, je ne pense pas qu'il faille commencer par une appli "tout compris", avec EJB ... Donc, je te dirais de faire du J2EE (en tout cas, de séparer les couches en dissociant ta logique métier de ta facade comme conseillé au dessus) mais sans sortir l'artillerie lourde.

[alexismp]

Pour la partie logique métier, et si ton planning le permet, regarde les EJB 3 (sortie finale dans environ un mois).
Ils préservent le coté implicite du contexte transactionnel et simplifient le développement en proposant des POJO.
Le serveur d'application open source GlassFish sera dispo en même temps que la spec.