Question pour validation d'une architecture !

Bonjour,


J'ai actuellement un problème de conception et j'hésite entre deux solutions ou peut être une troisième, mais dans ce cas là, je ne la connais pas encore.

Voici mon problème d'un commun... :
J'ai une architecture qui mets en place le modèle Facade + Service + DAO + Model métier pour la gestion de donnée metier hibernate.

D'un autre coté, j'ai mon IHM qui utilise des interfaces (getters/setters) classiques. Il faut donc que je lui injecte une implémentation appropriée.

Ma question est donc comment réaliser cette implémentation :
Solution 1 ) Mes objets métiers implémentent ces interfaces directement. Ce qui m'embête, c'est que j'ai l'impression de mélanger les deux.

Solution 2) J'ai une implémentation indépendante, et lorsque je souhaite sauver une de ces implémentations sous forme persistante, je passe par un convertisseur (il transforme mon implémentation en un objet métier), puis je sauve l'objet métier ainsi créé.

Qu'en pensez vous ?

Bonsoir

Pour répondre à la question franchement c'est la tester cette architecture avec un code minimal ou utiliser excel et comparer sur les critères recherchés(délai, performance, souplesse...)


Je ne suis pas sur de bien comprendre mais s'il s'agit de faire un couplage entre les objets métiers et IHM ce n'est effectivement pas la solution 1 à choisir.

Citation:

---

Envoyé par zuzuu

Solution 1 ) Mes objets métiers implémentent ces interfaces directement.

---

Quels interfaces ?

Une architecture qui pourrait te convenir :

- Objet Metiers directement persistables et utilisables partout. Pas besoin de convertisseurs.

- Objet pour la vue (utilisant les objets Metiers + service)
- Service (utilisant Objets Metiers + Dao)
- Dao (utilisant Objets Metiers + couche de persistance)

En generale cette architecture marche assez bien sur des application MVC, le fait d utiliser les objets metiers dans les 3 couches permet de limiter l emploi du pattern Value objet qui en general n est pas utile si on ne fait pas d acces Remote.

Rmq : Dans cette architecture tes objets metiers n implantent aucune interface a part peut etre Serializable des interfaces du domaines metiers.

Biensure, je te conseil fortement de faire des test unitaires sur ces 3 couches + le domaine metier.

Merci de vous être penchés sur ce problème. En fait, finalement, j'en suis venue à considérer les données de la couche présentation, comme de simple formulaire dont on transmet les informations aux façades afin d'obtenir des objets métiers.
Cela, fonctionne et nécessite une copie des informations dans les bons champs par contre.

Citation:

---

Envoyé par zuzuu

Cela, fonctionne et nécessite une copie des informations dans les bons champs par contre.

---

A ce propos, dans certaines approches, chaque formulaire rempli est vu comme un objet à part entière. Transférer les valeurs d'un formulaire (au sens strict du terme) vers le bons objet métier revient ainsi à faire une simple recopie des valeurs entre deux objets, à base de getters dans l'un, et de setters dans l'autre.

Mieux ! si l'on s'est au préalable fixé des conventions de nommages dans les attributs des classes, on peut carrément automatiser cette recopie avec la méthode statique copyProperties de la classe utilitaire BeanUtil (Voir ici).

Waw, merci pour l'info, je ne connaissais pas cette fonctionnalité. ;)