Discussion :

[java_fun]

bonjour, :o

pour vous mettre dans l image je développe un intranet en se basant sur le model MVC à 5 cauches classique : 8)

-Présentation
-DAO
-Contrôleur
-Métier
-base de données

je viens de découvrire strtuts & hibernet et j ai vite remarqué que se couple me facilite plusieures tâches et j aimerais savoir des gens qui ont eus l experience d introduire struts ou /et hibernet sur leur projet MVC type 1 qu elle est l a meilleure méthode possible afin de les intégrer sans avoir à retaper à zero.... !! es possible ?

[sleepy2002]

Bonjour,

Partant du principe que ton appli est déjà implémentée, si tu veux migrer vers Hibernate/Struts

1. Struts concerne la partie MVC2 :
- Controleur : Actions
- Modele: Beans
- Vue: JSP
2. Pour la couche métier, ben ça ne devrait pas bouger
3. La couche DAO, si tu utilises Eclipse, le plugin HibernateSynchonizer te facilitera la tache (génération automatique des DAO).
4. La Bdd, ça ne devrait pas bouger.

Pour Struts, il y aura autant d'Actions à écrire que de fonctionnalités mises à la disposition de l'utilisateur. Si tu as défini des interfaces pour les modules de ta couche métier, ce sera assez simple à mettre en oeuvre. Pour les ActionForms, c'est la même chose (x formulaires => x ActionForm, mais si certains sont réutilisables, tu peux toujours réduire ce nombre).

Pour la couche DAO/Hibernate, il faut veiller à ce qu'elle retourne bien des structures de données attendues par ta couche métier. Il ne faut pas hésiter à définir des interfaces afin de simplifier l'intégration (c'est pratique si tu veux changer un jour de couche DAO, comme par exemple JDO).

Ce qui est bien maintenant c'est que la facilité de mise en oeuvre et l'intégration de ces frameworks permettent de se focaliser sur le métier de l'application.

J'espère t'avoir pu t'apporter qq indices pour ton prochain développement.

Bon courage.

[dlemoing]

Comment je vois les choses, indépendamment de la techno utilisée :

- Base de données
- DAO : couche d'accès aux données, elle retourne généralement des objets faisant partie du Domain Model
- le Domain Model (tes objets métiers : commande, produit, ...) : modèle objet (données et comportement) de l'application. Il doit contenir une bonne partie de la logique métier pour ne pas être considéré comme "Anémique"
- la couche "Business" (ou métier) : définit l'interface pour les différents cas d'utilisation et une partie de la logique métier spécifique à certains use cases
- la présentation : un controleur le plus mince possible qui fait des appels sur la couche métier, récupére le modèle (domain model généralement ou DTO) et le passe à la vue (JSP, PDF, Velocity, ...)