Discussion :

[jbrichez]

Bonjour à tous,

Je code actuellement une application javafx et je me pose plusieurs questions d'un point de vue architecture de l'application:

1) Jusqu'a présent je codais sans framework, mais j'ai regardé un tuto qui montrait le fonctionnement du framework MVVMFx et celui-ci est intéressant. Cependant je me pose plusieurs questions:
1.1) A quoi sert les ModelView dans ce framework ? Moi mes valeurs sont binder directement dans le fichier .xml, je ne comprend pas l'intéret de rajouter un fichier qui gére l'état de la vue.
1.2) Comme je vais l'expliquer dans les questions suivantes: Ais-je besoin d'un système d'injection de dépendance ?

2) J'ai une base de donnée qui stocke les informations de mon application. La pluparts des informations que je ressors de celles-ci sont stockés dans des ObservableList puisque je m'en ressers pour mes controles (TableView, ComboBox etc..). J'ai différentes fenêtres qui permettent de modifier ces informations.

Concrétement j'ai une ObservableList qui contient 4 objets A venant de ma base de données. Je décide à l'aide mes GUI de modifier la valeur X de mon 2ième objet A, puis la valeur Y de mon 4ième objet A. Dois-je modifié les valeurs de ma BDD à chaque modification des valeurs de mes objects A ?

Si oui, cela impacte t-il considérablement les performances ?
Si non, dois-je attendre que l'utilisateur ferme l'application pour tout sauvergarder dans la BDD et donc utiliser ? Je créé alors une classe qui compendra toutes mes valeurs Observable et je l'ajoute aux controlleurs qui en ont besoins ? injection de dépendances ?


Il faut savoir que les informations de certaines ObservableList ne devront être (en principe) que très peu modifier, alors que d'autres seront modifier plus souvent. Un système hybride serait-il plus efficace ? (mixage entre sauvegarde en fin d'application et sauvegarde à la vollée ?)

3) Pour l'accès à ma BDD j'ai créer des DAO<T> et une DAOFactory qui me créer des DAO<T>. Cela est-il une bonne pratique ?

4) J'entend beaucoup parlé de memory leak. Quelles sont les choses dont je dois faire attention afin de ne pas exposer mon application à ce genre de problèmes ?

5) Je stocke la configuration de mon application dans les préférences système, grâce à ceci. Ma configuration contient par exemple: la langue de l'application, l'état des paramétres etc..
Actuellement ils sont accessible grâce à un objet static comme-ceci:

/**
* Donnée membre contenant la configuration effectuée par l'utilisateur
*/
public static Configuration configuration = new Configuration;

A chaque fois que je souhaite modifier celle-ci, je la récupére de cette maniére: "Main.configuration". Je ne sais pas si cela est la bonne manière de faire. Mettre en place de l'injection de dépendance ? Cela est-il judicieux ?

Merci pour vos réponses.

[Chatanga]

1.1) Framework [MVCP]{3,12}Fx

Si la vue est simple et que les données sont sous la bonne forme, un modèle de présentation peut en effet s’avérer inutile. Mais, si les choses se compliquent, un tel modèle devient vite indispensable. Imagine par exemple que tu développes un formulaire qui donne la possibilité de valider, mais aussi d’annuler, les changements de l’utilisateur et de revenir aux valeurs initiales. C’est pratique d’avoir un modèle de vue transactionnel piloté par le contrôleur. Ce dernier peut aussi faire ce travail, mais tu peux vouloir réutiliser ton modèle ailleurs, ou le générer automatiquement, ou bien simplement vouloir séparer les choses.

1.2) Injection de dépendances

Non. D’ailleurs, si tu te poses la question, c’est que tu n’en as pas besoin. Le point de départ idéal pour introduire une nouvelle approche, c’est de ressentir les contraintes et limitations de ce qu’on fait actuellement. C’est très important, car toute approche a ses désavantages et en adopter une sans réelles motivations est contre productif (mais hélas usuel). Concernant l’injection de dépendances, elle est surtout utile pour modulariser une application. Et quand je dis modulariser, c’est aussi pour exploiter cette modularité à travers différentes configurations de l’application et pas simplement pour découper en « modules » son application. Il est parfaitement légitime d’injecter manuellement les dépendances d’une application dans la fonction main, y compris dans une application imposante. C’est même mieux de le faire ainsi que de se forcer à utiliser un framework d’injection et introduire des contournements douteux pour garantir que les choses soient construites dans le bon ordre.

2) BDD

Si tu te soucies simplement de sauver tes données lorsque l’application se ferme, tu n’as pas besoin d’une BDD, mais simplement d’un fichier de sauvegarde. Une BDD fait toutefois bien plus, en garantissant notamment la cohérence de tes données. Par ailleurs, dupliquer les données et les garder sous la main (et, pire, les partager), c’est le point de départ pour des tas d’emmerdements. Une fonction, un écouteur par exemple, éventuellement développée par un autre, pourrait très bien utiliser cette donnée plus tard, la combiner avec d’autres qu’il aura relues dans la BDD... et faire n’importe quoi. Utiliser une BDD te force aussi à penser le caractère transactionnels de ce que fait l’utilisateur, notamment quand une exception est levée (un printStacktrace étant rarement à la hauteur). Cette problématique se marie toutefois très bien avec le point précédent : un modèle de présentation qui sert de tampon et constitue une transaction appliquée en bloc sur validation de la saisie globale. De manière très générale, il est toujours vertueux de simplifier au maximum l’état d’un système. Si tu peux dire qu’avant et après que l’utilisateur ait appuyé sur ton bouton, toutes tes données sont au chaud en BDD, cohérentes et persistées, sans être dupliquées / modifiées à droite et à gauche, c’est beaucoup plus facile à appréhender, documenter, faire évoluer. Enfin, les performances sont rarement un problème ici et les systèmes de BDD sont conçus pour ça.

3) DAO

Les bonnes pratiques qu’on ne comprend pas deviennent de mauvaises pratiques. La question est donc plutôt : à quoi ça sert. En l’occurrence : https://cyrille-herby.developpez.com...c-pattern-dao/. C’est donc un découpage pertinent, y compris si on ne fait pas évoluer la BDD par la suite (la factory devient facultative, mais ça ne coûte pas grand chose de la garder). La séparation induite est logique, clarifie les choses et, comme toute conception utile, simplifie les tests.

4) Fuites mémoire

Exposé ? Ce n’est pas un risque externe, mais interne. La « solution » est de garder à l’esprit qu’un garbage collector est un outil très pratique, mais qui ne te dispense nullement de penser à la durée de vie de tes objets et ressources. Ce peut être à travers une variable statique, des écouteurs qu’on a oublié de désabonner et qui écoutent des données, les empêchant d’être libérées, une tâche asynchrone qui vient s’enfiler dans une file d’attente et qui continue à référencer son contexte tant qu’elle n’est pas exécutée, etc.

5) Configuration

Préférence système ? Qu’est-ce que tu entends par là ? Pour une configuration utilisateur, ça semble curieux. Sinon, ce n’est pas la bonne manière. A moins de vouloir pondre un logiciel de qualité industrielle, évite comme la peste tout accès statique (et donc caché), sauf pour certains cas (en fait, le logger et c’est tout, et encore). Ça rend le code peu lisible et peu / pas testable. L’injection de dépendance peut aider pour injecter la configuration, mais difficile de la justifier par ce seul besoin. Il ne faut pas non plus voir l’injection comme une meilleure alternative à un constructeur de 40 paramètres. De la même manière, regrouper les paramètres entre eux n’est pas non plus une meilleur alternative et tombe sous le coup de la loi de Déméter. L’inversion (pas l’injection de dépendance) est par contre une solution, même s’il ne faut pas en attendre des miracles. Une classe qui a trop de dépendance est le signe d’une mauvaise conception qu’il ne faut pas chercher à dissimuler, mais à corriger.