Discussion :

[maserati]

Bonjour,

J'ai utilisé JSF pour développer une petite application de test unitaire, ( page.xhtml qui appellent des classe java dite Managedbean et ces dernier se connecte directement à la base de donnée via le connecteur JDBC )

Personnellement j'ai choisi cette méthode parceque c'est plus rapide, et plus facile, je devrai présenter ma soutenance et je dois défendre mes choix avec la façon la plus professionnel qui soit.

Pouvez-vous m'aider à me donner les avantages de ces choix avec les inconvénients des autres choix possible.

Je vous remercie infiniment.

[romaintaz]

Hello,

Je pense qu'il doit nous manquer des informations... sinon c'est assez étrange ce que tu fais là !
JSF est un framework de présentation (couche V - View - du MVC). Quel intérêt représente le framework ici ? A la limite, si c'est juste pour avoir une page web qui te permet de démarrer des tests unitaires, autant créer une simple page JSP et mettre une servlet en face...

Tu dis ensuite que tes ManagedBeans sont tes classes de test ? Pas sûr de bien comprendre pourquoi, mais bon. De plus, il faut plutôt éviter de mettre l'accès à la base de données directement dans les ManagedBeans. Normalement (mais hors d'un contexte de test), l'idéal c'est d'avoir ceci :

Pages web (XHTML) <-> ManagedBeans (beans JSF) <-> Couche Services <-> Couche DAO <-> Base de données

Je mettrais en avant un dernier point enfin : l'utilisation d'une base de données "réelle" pour les tests. Lorsqu'il s'agit de tests unitaires, il est préférable d'utiliser une base de données en mémoire, en particulier H2, pour tester sa couche DAO. La base en mémoire permet d'avoir plein d'avantages : rapidité, pas d'accès réseau, on se fiche de la gestion des données, i.e. si tu utilises une vraie base, il faut bien rollbacker tes modifications, de façon à rendre une base de données dans le même état qu'au début.
Pour tester des couches à un niveau plus haut, il faut mocker (je recommande Mockito par exemple) les autres couches plus basses. Par exemple, je veux tester la méthode d'ajout d'un utilisateur dans mon service UserService. Cette méthode fait appel à la méthode UserDao pour l'insertion réelle dans la BD. Du coup, je teste UserDao.addUser en utilisant une base H2. Quant au test de UserService.addUser, je vais mocker (c'est-à-dire simuler le comportement) de la méthode UserDao.addUser. Ainsi, mon test ne se concentrera que sur le code de la méthode de service, et pas sur celui du DAO.
Je sais pas si je suis très clair, mais n'hésite pas à demander plus d'infos.

Pour des tests plus poussés, par exemple de vrais tests d'intégration, où l'intérêt est de tester tous les composants ensemble, là, une vraie base de données peut être utilisée.

[maserati]

Pour info, je fais ni modification, ni insetion, ni suppression, ce que je fais c'est juste des selection et puis je teste si le champ 1 de la table X est égale au champs 1 de la table X' .....

voici ce que j'ai fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Pages web (XHTML) <-> ManagedBeans (beans JSF) <-> Base de données

maintenant j'ai pas utilisé les DAO ni la couche service, est-ce que c'est grave ? Sinon j'ai une soutenance très très prochainement, peux-tu m'aider à argumenter mes choix techniques SVP, je veux une vision d'ingénieur sur les choix de jsf, ManagedBean, Xhtml ...etc

Merci

[fxrobin]

Si ton souhait est d'argumenter sur JSF :
- framework MVC
- standardisé par JSR
- Spec incluse dans JEE5 et +
- grande communauté
- extensible
- adéquation avec le reste de la plateforme JEE (EJB, Servlets, etc.)
- AJAX par défaut (JSF 2.0)
- structuration en tempaltes (Facelets, par défaut en JSF 2.0)

et j'en oublie sûrement ...

[threshold]

si tu cherches des arguments chez les autres, c'est que toi même tu n'es pas convaincu par tes propres choix
mais à ta place, je justifierai le "break" du modèle MVC par le fait que l'objectif ne porte pas sur l'architecture de l'application qui n'est qu'un prototype, et que bien sûr, tu ne ferai pas ce choix pour une application en production