Critiques pour un projet Java/JEE

Salut,

Je suis actuellement en recherche active d'emploi en tant que développeur Java/JEE et je suis entrain de développer une application JEE pour mettre en pratiquer mes compétences et avoir un exemple à joindre à mes candidatures ;).
Le problème c'est que je ne possède pas une grande expérience et j'ai besoin d'un feedback d'un professionnel pour corriger ma solution et m'améliorer, afin de proposer un exemple digne de sois. Pour cela je me m'adresse à vous, la communauté de développez.net pour m'aider. 8-)

C'est une application web qui permet de gérer les projets agiles, les taches des projets et qui vas dans un futur proche permettre de gérer le processus entier d'un projet Agile, Gestion de Sprint, Gestion des équipes, Notification par Mail, Validation ..etc.

Outils : Netbeans, maven, Glassfish, mySQL, JPA/Hibernate, EJB, JSF/primefaces,

Ci-dessous le lien du projet sur Github.
https://github.com/vlocity/Agilator.git

J'espère avoir votre feedback.
Merci d'avance pour votre aide.

Quelque remarques vite fait:

• tes EJB, il n'est pas nécessaire de leur donner un nom. Tu n'a pas plusieurs implémentation de la même interfaces EJB, donc ce n'est pas nécessaire de discriminer.
• ton persistence.xml référence la base de données -> il est préférable de référencer un connection pool et de laisser la config base de donnée coté cnofig serveur. Tous les utilisateurs n'auront pas une db locale
• présence du persistence de test dans le persistence de prod -> bof bof. D'ailleurs si tu utilise un connection pool ce ne serait plus un problème.
• absence de scripts de création de la DB pour les nouveaux clients? Ce serait pratique pour installer d'avoir le script sql créant la base vide.
• Ton abstract dao prend en paramètre une instance alors qu'une classe lui aurait suffit
• Je ne suis personellement pas fan de l'idée de mettre I_ devant le nom d'une interface. Si tu regarde l'api java, ce n'est jamais fais. L'utilisateur de l'interface se fiche de savoir que c'est une interface, une classe abstraite ou concrète, il sait juste qu'il y a dessus des méthodes qu'il peux appeler.

tchize_ merci beaucoup pour tes remarques.
1. J’ai implémenté plusieurs types de DAO pour garder les fonctionnalités spécifiques séparées.
2. Je rencontre des erreurs en configurant une connection pool, j’ai besoin de plus de temps pour la corriger.
3. Quelle méthode propose tu pour configurer une base de donnée de test
4. Je ne vois pas l’utilité des scripts SQL puisque la base est généré automatiquement par Hibernate à partir des classes Entity .
5. J’ai essayé d’implémenter l’AbstractDAO avec un paramètre de type Class mais ça ne compile pas en utilisant la Criteria API
6. J’ai supprimé le I_ des noms d’interfaces.

Comment trouves tu les tests. Y’a-t-ils des failles/lacunes. J’ai voulu faire du TDD m’ais je n’ai pas pu le suivre correctement.

Citation:

---

Envoyé par velocity

tchize_ merci beaucoup pour tes remarques.
1. J’ai implémenté plusieurs types de DAO pour garder les fonctionnalités spécifiques séparées.

---

Je ne sais pas à quelle remarque tu fais référence, mais aucune n'est incompatible avec ça.

Citation:

---

Envoyé par velocity

3. Quelle méthode propose tu pour configurer une base de donnée de test

---

Le plus facile est uen connection pool. Le serveur de test aura juste un pool différent du serveur deprod, le code devient agnostique par rapport à la db

Citation:

---

Envoyé par velocity

4. Je ne vois pas l’utilité des scripts SQL puisque la base est généré automatiquement par Hibernate à partir des classes Entity .

---

Effectivement, je n'avais pas vu to hbm2ddlauto

Citation:

---

Envoyé par velocity

5. J’ai essayé d’implémenter l’AbstractDAO avec un paramètre de type Class mais ça ne compile pas en utilisant la Criteria API

---

Tu peux montrer?

Citation:

---

Envoyé par velocity

Comment trouves tu les tests. Y’a-t-ils des failles/lacunes. J’ai voulu faire du TDD m’ais je n’ai pas pu le suivre correctement.

---

Pas eu le temps de les regarder.