Discussion :

[Don_Pedro]

Bonjour,

J'aurais une question relative à la "bonne" façon de se servir des propriétés JavaFX (donc StringProperty, IntegerProperty, ...) en respectant le modèle MVC.

Est-ce que c'est "mal" de se servir de ces objets JavaFX dans le modèle ? Donc d'utiliser une StringProperty dans mon modèle, par exemple.

Merci d'avance !

[bouye]

Tu n'as pas vraiment de "bonne" et de "meilleure" implémentation / implémentation de référence du concept MVC.

• Swing utilise une implémentation M (les nombreuses classes de modeles pour chacun des contrôles) + VC (l'ui delegate de ce même contrôle)
• tandis que JavaFX utilise M (les données) + V (le skin) + C (le behavior).
• Mais le behavior n'est pas disponible dans l'API publique ce qui oblige donc a implémenter a nouveau un M + VC quand on crée des composants perso ou généralement tu vas coder ta vue directement comme un contrôleur.
• A moins d'utiliser FXML ce qui permet de retomber sur une sorte de M (les données) + V (le FXML qui fait en sorte office de skin) + C (son contrôleur).

Découpler un max c'est bien mais tu dois toujours te poser la question de "est-ce que le jeu en vaut la chandelle a l’échelle de mon projet, de mon équipe, des ressources que j'ai a disposition ?"

Après est-ce que c'est mal de se servir des propriétés FX dans le modèle ? A priori non, les propriétés sont totalement découplées de la couche UI rien n’empêche de les utiliser dans un tiers ou une couche plus basse. Évidement rajouter le support des propriétés FX dans une couche ou un tiers de bas niveau de l'application va engendrer un couplage fort entre ce projet et les runtimes FX, ce qui rendra plus difficile un éventuel portage ultérieur vers une autre technologie. Outre cette première considération, l'important c'est surtout de voir si l’intégration de ces propriétés ne va pas rendre la tache plus complexe (au niveau du code spaghetti), difficile a maintenir ou introduire des problèmes de performances, etc. Le support des propriétés réactive tend a rendre le code moins linéaire et donc plus difficile a saisir pour certaines personnes d'autant plus si on doit tout coder a mano sans utiliser de framework particulier. De même qu'a force de rajouter des écouteurs ici et la qu'on enlève jamais quand on en a terminé avec on finit par définir des dépendances cycliques fortes qui ralentissent ou empêchent la récupération de la mémoire.

Mais avoir des données/modèle réactives permet entre autre de les afficher dans plusieurs vues histoire d'avoir des présentation différentes d'une même donnée/modèle. Mais bon ça peut aussi se faire avec des écouteurs normaux (beans pas AWT) sans forcements passer par les propriétés.

Bref, pour revenir sur la question, pas mal de contrôles tels que TableView ou TreeTableView sont quand bien plus simples a coder lorsque le modèle supporte les propriétés FX. Pour d'autres (les graphes), de base, ils ne supportent que les données brutes.

[Don_Pedro]

Ok merci beaucoup pour ces éclaircissements. J'utilise toujours le FXML, je trouve ça plus agréable, mais je ne crée plus de package "controller" séparé de la vue car les fx:id (champs @FXML) ne sont pas trouvées automatiquement quand on édite le FXML avec un scene builder si le controller se trouve dans un package différent. Je me suis donc résigné à laisser les controllers de chaque fichier FXML dans le même package (mais c'est principalement de la paresse, avouons le ...)