Le meilleur moyen pour une interface graphique Swing de communiquer avec la logique du domaine?

Question

J'ai une certaine logique de domaine implémentée dans un certain nombre de POJO. Je veux écrire une interface utilisateur Swing pour permettre à l'utilisateur d'initier et voir les résultats de diverses actions de domaine.

Quel est le meilleur modèle/cadre/bibliothèque pour les communications entre l'interface utilisateur et le domaine? Cela se résume en:

• l'interface utilisateur étant capable de convertir un geste d'utilisateur dans une action de domaine
• le domaine étant en mesure d'envoyer état/résultat informations à l'interface utilisateur à des fins d'affichage

Je suis conscient de MVC comme un concept large et j'ai triché avec le modèle Observer (dont l'implémentation Java a quelques inconvénients si je comprends bien), mais je me demande s'il existe une meilleure pratique acceptée pour ce problème?

Answer 1

Certainement MVC - quelque chose comme ce example qui divise clairement les choses. Le problème avec les exemples Swing est qu'ils semblent montrer le MVC tout en travaillant dans le swing, ce qui ne me semble pas juste

Answer 2

J'ai utilisé le modèle Observer (en utilisant la magie AspectJ) avec un certain succès, mais j'ai trouvé qu'à moins d'être prudent, il est rapidement devenu un cluster .. euhh .. flick?

Il est rapidement devenu difficile à gérer et surtout extrêmement difficile à déboguer.

Edit:

Pour développer un peu sur ma réponse, que nous utilisions SWT, pas balancer, si YMMV. Nous avons essentiellement utilisé AspectJ pour raccorder le transfert de données des composants de l'interface utilisateur aux objets du modèle. Ces objets modèles étaient des POJO stupides.

La logique métier réelle a été effectuée en «surveillant» les objets du modèle avec AspectJ et en déclenchant l'événement requis s'ils changeaient. Donc, si vous modifiez une valeur dans une zone de texte, AspectJ se déclenchera et copiera cette valeur dans un POJO. Si ce champ dans le POJO avait un événement pour la logique métier , alors feu. Si cette logique modifiait les POJO (et elle le pouvait), AspectJ remarquerait et copierait la valeur du POJO dans le composant UI.

Answer 3

MVC est fantastique pour un widget individuel, mais il devient un peu indiscipliné quand vous Ont pages et forms avec beaucoup de widgets.

Une chose qui pourrait être intéressant de regarder dans (et je ne suis pas l'endosser, je n'ai pas réellement utilisé, vient d'implémenter quelque chose de très similaire pour moi-même) est le Beans Binding Framework (JSR295)