0% ont trouvé ce document utile (0 vote)
77 vues44 pages

Javafx - MVC: Mme Ilhame EL FARISSI

Modele view controller

Transféré par

khaoula.moussa.23
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

Thèmes abordés

  • Design pattern,
  • Entité,
  • Composants d'interface,
  • Indépendance des composants,
  • Packages,
  • Gestion des événements,
  • État du système,
  • Propriétés,
  • Réutilisabilité,
  • SceneBuilder
0% ont trouvé ce document utile (0 vote)
77 vues44 pages

Javafx - MVC: Mme Ilhame EL FARISSI

Modele view controller

Transféré par

khaoula.moussa.23
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

Thèmes abordés

  • Design pattern,
  • Entité,
  • Composants d'interface,
  • Indépendance des composants,
  • Packages,
  • Gestion des événements,
  • État du système,
  • Propriétés,
  • Réutilisabilité,
  • SceneBuilder

JAVAFX -MVC

Mme Ilhame EL FARISSI


Structure d’une application
interactive
La partie ‘visible’ (front office):
ce que l’on fait et ce que l’on voit
Interface Homme-Machine (IHM)
La partie ‘invisible’ (back office):
ce qu’il se passe
Traitements
Données (stockage et accès)
Communications
Front Office:
Ce que l’on fait et ce que l’on « voit »
La tâche de l’utilisateur et l’IHM de l’application
Interface non graphique:
Ex: Ligne de commande, tableau de commandes et indicateurs, …
Interface graphique (GUI):
Ex: Application standard Windows, page web, …
L’utilisateur ‘commande’ l’application
(programmation événementielle)
L’IHM doit être adaptée à la tâche
L’application doit être ‘réactive’ (pas de traitements trop
longs)
Front Office:
Ce que l’on fait et ce que l’on « voit »
Les entrées (ce que l’on fait)

Les sorties (ce que l’on voit)


Exemple: Jeu d’échecs
La tâche globale: jouer aux échecs!
Sous-tâche: déplacer les pièces
Interfaces utilisateur:
Back office:
Ce qu’il se passe
Le ‘noyau’ de l’application:
Fonctionnalités
Accès aux données
Traitement des données
Les données
Produit les résultats aux actions de l’utilisateur
Exemple: Jeu d’échecs
Fonctionnalités:
Jouer une partie
Déplacer des pièces
Gérer les tours de jeu
Joueur virtuel

Enregistrer une partie
Charger une partie
Données:
État de la partie en cours
Parties sauvegardées
Catalogues d’ouvertures
Liaison entre ces 2 parties d’une application?
Introduction à l'Architecture MVC : Concepts et
Historique

Il existe différentes manières de structurer le code des


applications interactives (celles qui comportent une interface
utilisateur).
Une des architectures, communément utilisée, et qui comporte de
nombreuses variantes, est connue sous l'acronyme MVC qui
signifie Model -View-Controller.
Dans cette architecture on divise le code des applications en entités
distinctes (modèles, vues et contrôleurs) qui communiquent entre
elles au moyen de divers mécanismes (invocation de méthodes,
génération et réception d'événements, liaisons entre propriétés,
…).
Cette architecture (ou modèle de conception, design pattern) a été
introduite avec le langage Smalltalk-80 dans le but de simplifier le
développement ainsi que la maintenance des applications, en
répartissant et en découplant les activités dans différents
sous-systèmes (plus ou moins) indépendants.
Introduction à l'Architecture MVC : Concepts et
Historique
Le principe de base de l'architecture MVC est relativement simple,
on divise le code du système interactif en trois parties distinctes :
Le ou les modèles(Models)qui se chargent de la gestion des données
(accès, transformations, calculs, etc.). Le modèle enregistre
(directement ou indirectement) l'état du système et le tient à jour.
Les vues(Views)qui comprennent tout ce qui touche à l'interface
utilisateur (composants, fenêtres, boîtes de dialogue) et qui a pour
tâche de présenter les informations (visualisation). Les vues
participent aussi à la détection de certaines actions de l'utilisateur
(clic sur un bouton, déplacement d'un curseur, geste swipe, saisie
d'un texte, …).
Les contrôleurs(Controllers)qui sont chargés de réagir aux actions
de l'utilisateur (clavier, souris, gestes) et à d'autres événements
internes (activités en tâches de fond, timer) ou externes (réseau,
serveur).
Une application peut également comporter du code qui n'est pas
directement affecté à l'une de ces trois parties (librairies générales,
classes utilitaires, etc.).
l'Architecture Modèle-Vue-Contrôleur(MVC)
Organiser, structurer une application interactive en
séparant:
Les données et leurs traitements:
Le Modèle
La représentation des données
La Vue
Le comportement de l’application
Le Contrôleur
l'Architecture Modèle-Vue-Contrôleur(MVC)
l'Architecture Modèle-Vue-Contrôleur(MVC)
l'Architecture Modèle-Vue-Contrôleur(MVC)
l'Architecture Modèle-Vue-Contrôleur(MVC)
l'Architecture Modèle-Vue-Contrôleur(MVC)
l'Architecture Modèle-Vue-Contrôleur(MVC)
Modèle

Le modèle(Model)est responsable de la gestion des


données qui caractérisent l'état du système et son
évolution.
Dans certaines situations (simples) le modèle peut contenir
lui-même les données mais, la plupart du temps, il agit comme un
intermédiaire (proxy)et gère l'accès aux données qui sont stockées
dans une base de données, un serveur d'informations, le cloud, …
Le modèle est souvent défini par une ou plusieurs interfaces Java qui
permettent de s'abstraire de la façon dont les données (les objets
métier) sont réellement stockées (notion de DAOData Access
Object).
Il offre également les méthodes et fonctions permettant de gérer,
transformer et manipuler ces données.
Les informations gérées par le modèle doivent être indépendantes
de la manière dont elles seront affichées. Le modèle doit pouvoir
exister indépendamment de la représentation visuelle des
données.
Modèle
Le modèle:
Représente les données
Fournit les accès aux données
Fournit les traitements applicables aux données
Expose les fonctionnalités de l’application
Noyau Fonctionnel de l’application
Vue
La vue(View)est chargée de la représentation visuelle des
informations en faisant appel à des écrans, des fenêtres, des
composants, des conteneurs (layout), des boîtes de dialogue,
etc.
Plusieurs vues différentes peuvent être basées sur le même modèle
(plusieurs représentations possibles d'un même jeu de données).
La vue intercepte certaines actions de l'utilisateur et les transmet au
contrôleur pour qu'il les traite (souris, clavier, gestes, …).
La mise à jour de la vue peut être déclenchée par un contrôleur ou par un
événement signalant un changement intervenu dans les données du
modèle par exemple (mode asynchrone).
La représentation visuelle des informations affichées peut dépendre du
Look-and-Feelad opté (ou imposé) et peut varier d'une plateforme à
l'autre. L'utilisateur peut parfois modifier lui même le thème de
présentation des informations.
Vue
La vue:
Représente la (ou une) représentation des données du modèle
Assure la consistance entre la représentation qu’elle donne et
l’état du modèle/le contexte de l’application
Sorties de l’application
Contrôleur

Le contrôleur(Controller)est chargé de réagir aux


différentes actions de l'utilisateur ou à d'autres
événements qui peuvent survenir.
Le contrôleur définit le comportement de l'application et sa logique
(comment elle réagit aux sollicitations, business logic).
Dans les applications simples, le contrôleur gère la synchronisation
entre la vue et le modèle (rôle de chef d'orchestre).
Le contrôleur est informé des événements qui doivent être traités
et sait d'où ils proviennent.
La plupart des actions étant interceptées (ou en lien) avec la vue, il
existe un couplage assez fort entre la vue et le contrôleur.
Le contrôleur communique généralement avec le modèle et avec la
vue. C'est le sens des transferts et le mode de communication qui
caractérisent différentes variantes de l'architecture MVC.
Contrôleur
Le contrôleur:
Représente le comportement de l’application face aux actions
de l’utilisateur
Fournit la traduction des actions de l’utilisateur en actions sur
le modèle
Fournit la vue appropriée par rapport aux actions de
l’utilisateur et des réactions du modèle
Comportement et gestion des entrées de
l’application
Avantages de MVC
Structure ‘propre’ de l’application
Indépendance ‘données’ – ‘représentation’ –
‘comportements’
Adapté aux concepts de la programmation 0-0
Modulaire et réutilisable
Vues interchangeables
Contrôleurs interchangeables
Changement de ‘Look & Feel’
Facilite les vues et contrôleurs multiples
Synchronisation ‘quasi-implicite’
Inconvénients de MVC
Mise en place complexe dans le cas d’applications
importantes
Mises à jour potentiellement trop nombreuses
Temps d’exécution
Contrôleur et Vue restent souvent fortement liés au
Modèle
Adapter la réalisation au problème
Exemple complet d'application JavaFX utilisant
SceneBuilder, NetBeans et MySQL

Objectif : Développer une application simple de gestion de produits en


respectant le modèle MVC.
Préparation de l'environnement
Installation des outils nécessaires
SceneBuilder : pour concevoir l'interface utilisateur.
NetBeans : pour développer et exécuter le projet.
MySQL Community Server : pour gérer la base de
données.
Configuration de la base de données
Création d’une base de données product_db et une table
product
Création et configuration du projet
Création du projet
Ajout du driver JDBC
(Pour Netbeans) Ajoutez-le dans les bibliothèques du projet
via Project Properties > Libraries > Add JAR/Folder.
Structure du projet selon MVC :
Divisez le projet en trois packages :
model : contient les classes liées aux données (entité et
DAO).
view : contient les fichiers FXML définissant l'interface
graphique.
controller : contient les classes gérant les interactions
utilisateur.
Résumé des concepts abordés :
Modèle MVC :
Modèle : Gestion des données avec Product et ProductDAO.
Vue : Interface utilisateur créée avec SceneBuilder et FXML.
Contrôleur : Coordination des actions entre l'utilisateur,
l'interface et le modèle.
Connexion MySQL avec JDBC pour les opérations
CRUD.
Utilisation de JavaFX pour développer une interface
utilisateur dynamique.
Implémentation de l'exemple (Modèle):
Création d’une classe Product représentant un produit
avec des propriétés (id, nom, prix).
Implémentation d’une classe ProductDAO pour gérer
l'accès à la base de données :
Méthode pour récupérer tous les produits de la table product.
Méthode pour insérer un nouveau produit dans la base de
données.
Classe Product (Entité)
Cette classe représente un produit avec des propriétés (id,
nom, prix).
Classe ProductDAO (Accès aux données)
Cette classe gère les opérations de la base de données
comme récupérer ou insérer des produits.
Implémentation de l'exemple (Vue):
Utilisation de SceneBuilder pour créer une interface
graphique :
Une TableView pour afficher les produits.
Deux TextField pour entrer le nom et le prix.
Un Button pour ajouter un produit.
Sauvegarde de l'interface dans un fichier
ProductView.fxml.
Implémentation de l'exemple (Vue):
Implémentation de l'exemple (Vue):
Implémentation de l'exemple(Contrôleur):
Création d’une classe ProductController pour gérer les
interactions utilisateur :
Configuration des colonnes de la TableView avec les données
des produits.
Implémentation d’une méthode pour ajouter un produit :
Récupérez les données saisies par l'utilisateur.
Appelez ProductDAO pour insérer le produit dans la base.
Mettez à jour la TableView.
Implémentation de l'exemple(Contrôleur):
Implémentation de l'exemple(Contrôleur):
Classe principale :
Implémentez une classe Main pour charger l'interface
utilisateur et lancer l'application.
Lancement du projet

Vous aimerez peut-être aussi