Le Jeudi 9 Janvier 2003 13:11, Sebastien Cesbron a �crit :

> 1 - d�finir des interfaces de visu sur mes objets m�tier

C'est ce que je fais. Et j'ajoute des r�gles de visibilit� (private, 
protected, default, public) les plus strictes possibles, et en s�parant les 
paquages m�tier et pr�sentation.

L'inconv�nient est que l'objet m�tier "connait" un tant soit peu la 
pr�sentation, puisqu'il met en oeuvre l'interface pr�sentation. Si l'on 
arrive mal � s�parer m�tier et pr�sentation, cet inconv�nient peut devenir 
critique.

Habituellement c'est l'objet m�tier qui concr�tise directement l'interface. Si 
je veux �tre plus s�v�re, je cr�e une inner class de l'objet m�tier (ou 
quelque fois une classe s�par�e) qui met en oeuvre l'interface. Ainsi le cast 
depuis la pr�sentation devient quasi impossible.

L'interface est pas mal parce qu'elle permet de fa�on simple � la fois la 
visualisation m�tier, et la modification m�tier depuis la visualisation ; il 
ne faut pas oublier que la pr�sentation visualise, mais aussi qu'elle peut 
modifier. D'ailleurs on peut se demander des fois qui interface qui.


> 2 - cloner mes objets m�tier avant de les transmettre � la pr�sentation

Pas facile � g�rer � cause des probl�mes de clone des attributs. Je le fais 
pour les cas o� la pr�sentation oblige � une modification ponctuelle de 
l'objet m�tier (mauvaise conception au d�part, allez-vous me dire) (je 
voudrais vous y voir).

N�anmoins, si tu veux �tre s�r qu'il n'y ait aucune modif m�tier issue de la 
pr�sentation, il faut cloner tout ce que tu lui transmet, m�me si c'est par 
l'interm�diaire d'une interface.


> 3 - diviser mes objets m�tier en deux objets : les r�gles de gestion et
> l'�tat et ne transmettre que l'objet correspondant � l'�tat.
>

Trop intellectuel.

Une quatri�me possibilit�, que j'utilise souvent, est le mod�le d'�v�nement en 
listener/events. Cela fonctionne bien lorsque tu as plusieurs objets de 
pr�sentation pour un seul objet m�tier, ou que tu ne sais pas trop � l'avance 
quelle sera la pr�sentation. Mais cela oblige � une gestion des �v�nements 
qui peut �tre ardue. (et en y r�fl�chissant cela revient � ton 3).

Une cinqui�me possibilit� est le fonctionnement par messagerie (voir JMS), en 
asynchrone. L� la s�paration est quasi compl�te (mais abouti encore une fois 
� un clone), la gestion des thread tr�s s�re, mais cela oblige � faire tr�s 
attention au niveau des �tats des uns et des autres, et souvent � r�inventer 
la roue au niveau de la transmission des param�tres.


> Aucune de ces trois possibilit�s ne me satisfait pleinement notamment
> dans le cas o� j'ai un objet m�tier avec un lien n vers un autre. Existe
> t'il d'autres possibilit�s ?
>

Je vois pas le rapport avec les liens. Tu as un objet m�tier A avec un lien n 
avec d'autres objets m�tiers, la pr�sentation de l'objet A pr�sente l'objet A 
et ce qu'il veut bien dire des objets li�s. O� est le probl�me ?


-- 
SARL diaam informatique - 04 50 77 12 60
Ingenierie, d�veloppements de syst�mes d'information
http://www.diaam-informatique.com


Répondre à