application web ou bien normale

Bonjour,
Je veux rèaliser une application java pour la gestion des personnels d une entreprise, mais je ne sais pas est ce que c est mieux de rèaliser une application Web(intranet à l entreprise) ou bien une application normale??
Si j ai choisi de faire une application normale est ce que c est suffisant de la faire par : JAVA , Mysql5 et pour rèaliser mes interfaces : je dois utiliser awt et swing ? et au niveau l accès à la base de donnèes je ferai un accès direct(pas de mapping) est ce que ça c est bon ou bien c est mieux d utiliser un outil de mapping (hibernate ...) est ce que ça va donner une plus à l application car j ai jamais travailler avec hibernate au niveau d une application normal
J ai besoin de vos rèponses pour commencer mon projet
Merci à ts

Sur l'aspect appli web / client lourd, ça dépend vraiment de l'entreprise.

L'appli web ça garantit la facilité d'utilisation et ça permet d'ajouter de la sécurité.

Le client lourd ça garantit que tu es beaucoup plus à l'aise sur ce que tu peux implémenter en terme d'interface :)

Quant à l'utilisation d'hibernate ou autre framework de persistance, c'est vraiment très pratique à utiliser.

En intranet, l'application web se défend bien, rien à installer sur les postes clients, centralisation de l'accès aux données donc meilleurs sécurité des données.
En revanche, la "richesse" ergonomique de l'application sera un poil en dessous... et si tu dois faire du graphique, c'est plus compliqué...

Sinon, pour les framework ORM, c'est très bien, mais il faut un temps d'apprentissage conséquent. Si la base de données est unique et fixée, l'accès par JDBC donne de très bons résultats (imbattables si tu passes par des procédures stockées). Ensuite, ça dépend un peu de la complexité de l'application aussi. Pour la mise à jour de tables multiples liées par une hiérarchie, ça simplifie la tâche.

Pour le client lourd, il faudrait plutôt prendre Swing, AWT est obsolète.
Ceci dit, Swing n'est pas simple à appréhender non plus...

En dernier lieu, tu as la possibilité de faire un mixe des 2.
Tu fais un client lourd qui utilise des EJB pour la partie métier (sur un serveur d'application)...

Bon choix...:mrgreen:

Merci pour vos rèponses
J ai dècidè de faire un intranet (web) en jsf et hibernate (selon la premiere reponse)
Mais ce qui je n ai pas compris qu est ce que vous voulez me dire par(2 eme rèponse)

Citation:

---

En dernier lieu, tu as la possibilité de faire un mixe des 2.
Tu fais un client lourd qui utilise des EJB pour la partie métier (sur un serveur d'application)...

---

Je n ai pas compris ça , je peux mixer entre quoi et quoi:
Etre l utilisation d une apllication normale et web (jamais j ai fait ça)
Ou bien entre l utilsation par exemple d Hibernate & l accès directe à la base de donnèes??
Pourriez vous m eclairsser les choses SVP

Tu peux avoir un client lourd qui se connecte à un serveur EJB, ce qui combine la richesse ergonomique et la sécurité / centralisation.

Mais, forcément, c'est plus lourd à mettre en place ;)

Sur Hibernate, c'est vrai qu'il y a un temps de prise en main, donc si tu es limite sur le temps, c'est peut-être pas la peine ; sinon c'est plus souple ensuite, et puis ça te fait monter en compétence :ccool:

Citation:

---

centralisation de l'accès aux données

---

Je ne vois pas vrai ce qu'une version web change d'un client lourd point de vue accès aux données :O

Par contre oui, l'application web est bien plus facile à mettre à jour..
Bien que si on effectue pas de mises à jour 24/7, un petit fichier batch par exemple pourrait s'occuper de remplacer les versions précédentes sur les postes clients :roll:

Maintenant il faut voir tes connaissances, si tu as une bonne maîtrise de HTML/CSS/JAVASCRIPT, tu auras vite fait de faire un design plus que potable bien qu'on est pas aussi à l'aise qu'avec swing :P

Citation:

---

Envoyé par sonia5

Je n ai pas compris ça , je peux mixer entre quoi et quoi:
Etre l utilisation d une apllication normale et web (jamais j ai fait ça)

---

Ce n'est pas entre un client lourd et une application web mais plutôt entre un client lourd et un serveur d'application (typiquement utilisé par une application web), je me suis mal exprimé... :aie:

Pour ton choix, Jsf + Hibernate, c'est un bon choix... mais j'espère que tu connais Jsf parce que là non plus, ça ne se fait pas tout seul... (temps d'apprentissage).
Dans ce type d'architecture, tu peux accessoirement combiner :
- JSF
- Facelets
- RichFaces
- Seam
- EJB3 (via Hibernate par exemple)

EJB3 ne représente pas vraiment un surcroit d'apprentissage par rapport à Hibernate (natif), ça t'oblige par contre à avoir un conteneur d'EJB sur ton serveur (donc pas avec Tomcat de base... mais tu peux lui rajouter un plugin pour le faire ;)).
RichFaces d'un point de vue richesse de composant, ergonomie, look & feel, je trouve que c'est le top... (de ce que je connais en tout cas)
Facelets, c'est pour le "templating"
Seam pour la "glue" entre le monde JSF et EJB3

Citation:

---

Envoyé par libuma

Je ne vois pas vrai ce qu'une version web change d'un client lourd point de vue accès aux données :O

---

Eh bien ça dépend de si ton client lourd va directement interroger la base, ou s'il passe par un serveur d'application (le 3ème cas évoqué ici). Dans ce dernier cas, tu peux centraliser de la logique métier, augmenter la sécurité, etc. Par ailleurs tu es sûr d'avoir un bon contrôle sur les façons d'accéder aux données.

Citation:

---

Maintenant il faut voir tes connaissances, si tu as une bonne maîtrise de HTML/CSS/JAVASCRIPT, tu auras vite fait de faire un design plus que potable bien qu'on est pas aussi à l'aise qu'avec swing :P

---

Tant que tu ne veux pas afficher de choses trop exotiques, oui, on est bien d'accord? C'est là qu'il faut faire un cahier des charges de ce qui devra être affiché et des interactions dans chaque écran, pour se faire une idée.

Citation:

---

Envoyé par Rei Ichido

Eh bien ça dépend de si ton client lourd va directement interroger la base, ou s'il passe par un serveur d'application (le 3ème cas évoqué ici). Dans ce dernier cas, tu peux centraliser de la logique métier, augmenter la sécurité, etc. Par ailleurs tu es sûr d'avoir un bon contrôle sur les façons d'accéder aux données.

---

Qu'est-ce que le serveur d'application apporte de plus concrètement ?
Si l'application ne fait que des appels à des procédures stockées oracle par exemple, centralisées dans une classe métier avec éventuellement des logs..

Citation:

---

Envoyé par OButterlin

Dans ce type d'architecture, tu peux accessoirement combiner :
- JSF
- Facelets
- RichFaces
- Seam
- EJB3 (via Hibernate par exemple)

---

Nan mais vous êtes malade de conseiller ça... :aie:
C'est le mélange le plus long à comprendre et le ticket d'entrée le plus cher, dans les 3 ou 4 mois pour commencer a pondre un truc cohérent.

Java/JSP/Servlet sur un Struts ou un framework comme Wicket, en 1 semaine un informaticien lambda est opérationnel. Ressource facile à trouver et maintenance simple.

Citation:

---

Envoyé par libuma

Qu'est-ce que le serveur d'application apporte de plus concrètement ?
Si l'application ne fait que des appels à des procédures stockées oracle par exemple, centralisées dans une classe métier avec éventuellement des logs..

---

L'opportunité de ne pas utiliser les procédures stockées pour une utilisation/centralisation similaire.
Indirectement, une plus grande portabilité et accessoirement la possibilité de faire facilement du load balancing dans le cadre de fortes montées en charge.
(par défaut avec JDBC, que je sache, on se connecte à UN seul serveur)

Citation:

---

Envoyé par Jimmy_

Nan mais vous êtes malade de conseiller ça... :aie:
C'est le mélange le plus long à comprendre et le ticket d'entrée le plus cher, dans les 3 ou 4 mois pour commencer a pondre un truc cohérent.

Java/JSP/Servlet sur un Struts ou un framework comme Wicket, en 1 semaine un informaticien lambda est opérationnel. Ressource facile à trouver et maintenance simple.

---

LA BLAGUE ! 8O :mouarf:

On n'a visiblement pas la même expérience...
Faire un truc chiadé avec des JSP/Servlet ou JSP/Struts, c'est la galère assurée... mais s'il s'agit de faire des formulaires basiques pourquoi pas... en 1 semaine...

JSF/RichFaces est super simple à utiliser, je ne vois pas où est le problème.

Pour le reste, on était dans la cadre de l'utilisation d'Hibernate, donc, il n'y a pas de surcroit d'apprentissage significatif pour EJB3.
Seam simplifie également l'usage des EJB dans une application JSF... retenu également...

Bref, qui est malade ?

Citation:

---

Envoyé par OButterlin

LA BLAGUE ! 8O :mouarf:

On n'a visiblement pas la même expérience...

---

Je crois que le soucis est là...

Mais enfin bon JSF+Seam+hibernate vous aimez le xml j'espère ?
Un petit peu de Spring aussi non ?

Ca m'étonne plus que ma direction veux passer à .NET quand je vois que sur un forum comme celui-ci on s'entête à conseiller ce genre de montage.

Citation:

---

Envoyé par Jimmy_

Mais enfin bon JSF+Seam+hibernate vous aimez le xml j'espère ?
Un petit peu de Spring aussi non ?

---

Le message type de la personne qui parle sans connaître :roll:

Citation:

---

Envoyé par Jimmy_

Ca m'étonne plus que ma direction veux passer à .NET quand je vois que sur un forum comme celui-ci on s'entête à conseiller ce genre de montage.

---

On ne s'entête pas, on utilise... on sait de quoi on parle (nous).

Ta direction à le droit de choisir .NET, ça ne regarde qu'elle et ça ne sous-entend en aucun cas que c'est mieux que JEE.
Quand on développe de l'intranet, pourquoi pas... pour le reste... ça ne tient pas la route.

Citation:

---

Le message type de la personne qui parle sans connaître

---

Bien sûr que ci, c'est même un echec d'un projet de 12M€ basé sur JSF/Seam/Spring mon expérience. Trop compliqué à développer et trop compliqué à maintenir.

Citation:

---

On ne s'entête pas, on utilise... on sait de quoi on parle (nous).

---

Oui oui j'utilise je suis même au support depuis 12 ans d'une grande société qui utilise 11 frameworks J2EE différents.

Donc mon conseil est d'éviter les empilements technologiques avec Java et de se tourner par exemple vers du Wicket qui n'est que JAVA/html ou si les formulaires sont simples JSP/Servlet. Vous trouverez toujours des ressources pour le faire, simplement et pas cher.

Soit, c'est curieux mais c'est ton expérience.
Ceci dit, je n'aurais pas associé Seam à Spring mais Seam à EJB3.
(je ne vois pas l'apport de Spring par rapport à EJB3)

Pour une application qui doit booster, il semble que Wicket soit très bien (mais je ne le connais pas)

Sinon, il y a des solutions à base de Tapestry ou Velocity et bien d'autres... dont struts que j'apprécie particulièrement pour sa robustesse (mais plutôt couplé à tiles et struts-layout).

Citation:

---

Envoyé par OButterlin

Pour une application qui doit booster, il semble que Wicket soit très bien (mais je ne le connais pas)

---

Framework J2EE orienté composant, avec uniquement du Java/Html d'une productivité redoutable et avec le support de la communauté Apache, difficile de rêver mieux dans l'univers open source.

La vèritè vous me donnez pls possiblitès ce que me difficille le choix des technologies à utiliser
Je dois faire un travail pour 4 mois (projet de fin d'ètudes (bac+5))
J'ai dècidè d'utiliser :
JSF
Hibernate
Mysql5
et qu est ce que je dois utiliser au niveau de ma couche mètier , est ce que les beans prèsntent cette couche??
Merci à ts

Salut,

étant donné tes choix, je te conseille d'utiliser un bon conteneur d'EJB (Glassfish parce que ca roxx!) pour ta couche de service...

Abstrais un peu plus ta couche d'accès aux données en utilisant JPA (libre à toi d'utiliser Hibernate comme provider cela dit)...

Donc au final un bon projet JEE standard:

- Serveur d'appli Glassfish V3 (JEE6)
- JSF -> web
- EJB 3.1 -> service
- JPA (provider hibernate si tu veux) + EntityBean -> dao
- MySql -> persistance

++

D accord

Citation:

---

- Serveur d'appli Glassfish V3 (JEE6)
- JSF -> web
- EJB 3.1 -> service
- JPA (provider hibernate si tu veux) + EntityBean -> dao
- MySql -> persistance

---

Mnt vous m orientez vers le bon choix:
Mais:
pour le serveur d appli je vais utiliser : Apache Tomcat au lieu de Glassfish car j ai dèjà l utiliser
Et pour EJB : je vais utiliser des beans normals , est ce que pour travailler par ejb3.1 je dois télécharger des librairies (jar...) ?? je peux utiliser seulement des classes java (beans) pour faciliter la communication entre DAO et Presentation est ce que ça aussi segnifie que j utilise ejb mais comment je peux faire il s agit de quelle version?
dans l attente de vos rèponses car je dois commencer mon projet
Merci à ts

:aie: Aie! Tomcat est un simple conteneur de servlet, donc pas d'EJB :cry:...

Je crois qu'il y a une extension de Tomcat qui simule plus ou moins un conteneur d'EJB mais je ne me souviens ni son nom, ni s'il est viable.

Au pire pour ta couche service il y a Spring qui s'intègre bien avec Tomcat mais ca risque d'être lourd à appréhender en 4 mois.

Wait and see, je n'ai pas assez de background pour te guider vers quelque chose de pertinent si ce n'est pas FULL JEE (et je te déconseille fortement de le faire à la mano si tu as des contextes transactionnelles un tantinet complexes)

Les experts des SI qui squattent sur le fofo t'orienteront vers une solution acceptable quant à ta couche de services.

A plus

Par défaut, ce sera sans EJB avec Tomcat, à moins d'installer OpenEJB.
Sinon, rien ne t'empêche d'utiliser des classes java simples, le plus important étant de bien découper les couches.
Généralement, on retrouve :
- la couche présentation (JSP)
- la couche contrôleur (Servlet)
- la couche métier (java Beans)
- la couche d'accès aux données (DAO, java Beans), dans ton cas, avec Hibernate.

A+