Responsabilité Struts / Spring

Bonjour à tous,
Je bosse sur un projet d'appli web ou nous utilisons Struts, Spring et Hibernate.
J'ai un doute sur la façon dont nous avons développé, et de "la bonne place" du code entre les deux premières couches, Struts et Spring. (côté Hibernate no soucy).
Je précise qu'actuellement cela fonctionne, mais que l'on est pas dans les normes.

Ex fonctionnel :
Enregistrement d'un mouvement de stock.
Pour un produit / une quantité donnés, on doit enregistrer en BDD un tuple (produit, quantité, entree/sortie).
On doit ensuite décrémenter le stock pour le produit/la quantité donnés.

Actuellement :
Nous avons les classes suivantes :
- deux javabeans,
- une action,
- une interface Spring "Bo"
- une classe Spring "BoImpl"
- une interface Hibernate "Dao"
- une classe Hibernate "DaoImpl"

Ce qui se passe, c'est que la classe Spring BoImpl ne contient aucun code métier. Elle fait directement appel à l'interface Dao et ne contient rien dans son corps. Tout se passe dans l'action.

L'action Struts récupère les deux paramètres et fait les traitements suivants. [le code n'est pas exhaustif, je ne l'ai pas sous les yeux]

Code:

---

1 2 3

String refproduit = getId_produit(); int quantitemvmt = getQuantite();

---

dans l'action : pour le produit, on a la référence, et on va chercher l'objet entier en BDD

Code:

---

1 2	produit = produitbo.findProduitById(getId_produit());

---

(exemple code ProduitBoImpl)

Code:

---

1 2 3 4

public findProduitById(String refproduit){ return produitdao.findProduitById(refproduit) }

---

dans l'action : ensuite, création du Mouvement de stock, et sauvegarde

Code:

---

1 2 3

mvmtstock = new MouvementStock(produit, quantitemvmt,"sortie") mvmtstockbo.save(mvmtstock)

---

dans l'action : ensuite, on décrémente le Stock et on le sauvegarde

Code:

---

1 2 3 4

stock = stockbo.findStockByProduit(produit); stock.setQuantite = stock.getQuantite()-quantitemvmt; stockbo.save(stock);

---

Je ne sais pas si c'est très clair mais je n'ai pas le code sous les yeux.
Ce qui m'a frappé c'est que les BoImpl ne contiennent pas de code.

Par exemple, ne serait ce pas de la responsabilité de BoImpl de définir la nouvelle quantité du stock ?

Dans ce cas, à quoi se limite l'action ? Juste à la récupération des paramètres ?

Merci d'avance de votre retour.
Olivier

Hello,

Je vois bien ce que le développeur a tenté de faire. Ca me paraît effectivement pas super courant mais bon...pourquoi pas à la limite.
Les 2 approches classiquement utilisées par les devs sont l'approche SOA ou l'approche Model Driven (Active Record).

La le dev a fait une espèce de mix un peu perturbant.

• L'idée SOA c'est : Le controleur (Action Struts) exploite un ensemble de services qui exploite un ensemble de DAO. Les Objets métier et dits "de présentation" naviguent entre ses couches et son complètement agnostics (pas d'intelligence dedans)

• L'idée ActiveRecord : Les objets métiers sont "intélligent" et sont en capacité de contrôler leur propre persistance. C'est la solution choisie ici mais avec l'introduction d'une couche DAO "parasite".

Sur ta question concernant la quantité de stock, là je crains ne pas saisir.

Sur la question, que fait un contrôleur, moi je dirai un peu de façon un peu "sarcastique" : essentiellement encapsuler le traitement de formulaires.
Après c'est selon l'architecture choisie (SOA / ActiveRecord).
Note que je précise souvent : En tous cas ce n'est pas lui qui à la charge de la gestion transactionnelle.

A+