JavaFX - la bonne façon d'utiliser les propriétés avec des objets de domaine

JavaFX a fourni un tas de nouveaux objets Property, tels que ceux javafx.beans.property.DoublePropertyqui vous permettent de définir des champs qui peuvent être automatiquement observés et synchronisés.

Dans de nombreux exemples JFX, la classe de modèle MVC possède un certain nombre de ces champs de propriété, qui peuvent ensuite se lier automatiquement à la vue.

Cependant, cela semble nous encourager à mettre des propriétés JFX dans nos objets de domaine (si vous supposez que la classe Model va être un objet de domaine), ce qui me semble être une mauvaise séparation des préoccupations (c'est-à-dire mettre du code GUI dans le domaine ).

Quelqu'un a-t-il vu ce problème résolu dans la «vraie vie» et, dans l'affirmative, comment a-t-il été fait?

J'ai joué avec JavaFX 2.0, dont je suppose que votre question concerne. Pas un vrai code de production, juste un projet personnel, mais j'ai rencontré le même problème que vous mentionnez ci-dessus. Le modèle entier a tendance à devenir dépendant du cadre 2D, et je ne l'aime pas.

Ce que j'ai fait, c'est que j'ai divisé chaque classe du modèle en deux, la vraie classe de modèle, qui a les capacités de charger son contenu à partir de la base de données, sait comment il modifie son état, etc etc ... et la classe de représentation qui décide de l'apparence À l'écran. Ce dernier contiendrait toutes les classes de propriétés.

Vous trouverez le même design dans n'importe quel framework MVC, comme Swing. c'est juste qu'ici, il n'y a pas d'échappatoire.

Près de 7 ans plus tard et cette question est toujours aussi valable qu'auparavant.

À mon avis, javafx ne devrait jamais être importé par aucune des classes appartenant au modèle. Cependant, ils peuvent fonctionner très bien si vous adoptez une MVVM combinée à une architecture MVC. En ce sens, le

• entités = modèle (domaine) ( M )
• Fichiers FXML = vue ( V )
• le contrôleur est toujours le contrôleur ( C )
• le modèle de vue ( VM ) = un nouvel ensemble de classes de données qui ne contiennent que des propriétés javafx et une référence à l'objet de domaine réel (M) qu'il représente. Il peut passer des appels de méthode de logique métier plus loin à cet objet, agissant comme un composite / décorateur.

Une autre façon de voir les choses est de considérer la classe de contrôleur comme faisant partie de la vue, car elle ne fait que lier le modèle de vue à la vue (données et actions). On pourrait donc facilement l'appeler un présentateur ou même un classeur. Cela dépend cependant de la façon dont vous utilisez le contrôleur. Si vous ajoutez une logique pour manipuler le modèle de vue dans la classe Controller, alors il mérite son nom et vous avez l'architecture présentée ci-dessus. Si la classe de contrôleur lie uniquement les données de modèle aux éléments d'interface utilisateur et ActionEvents aux méthodes de modèle, alors vous avez tendance à avoir l'architecture mutante MVVM présentée ci-dessous.

Je pense que ces architectures correspondent en quelque sorte aux idées d'oncle Bob sur l'architecture propre (la couche de présentation).