Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Delphi 10.3
  3. Utilisation du design pattern MVC
Extrait - Delphi 10.3 Programmation orientée objet en environnement Windows
Extraits du livre
Delphi 10.3 Programmation orientée objet en environnement Windows
9 avis
Revenir à la page d'achat du livre

Utilisation du design pattern MVC

Introduction

Tous les objets enregistrés dans la base de données précédente sont amenés à être achetés par des utilisateurs inscrits de l’application ECommerce.

Dans ce chapitre, il va être décrit comment concevoir une telle application en utilisant un design pattern MVC (pour Model View Controller). Ce sera l’occasion de voir quels sont ses avantages et comment on peut passer d’une architecture monolithique à une architecture « N-Tiers », qui représente l’architecture de la majorité des applications sur Internet.

Design pattern MVC

Le design pattern MVC, ou motif de conception MVC, est composé de trois types de modules ayant trois responsabilités différentes, à savoir les modèles, les vues et les contrôleurs :

  • Un modèle (Model) contient les données à afficher.

  • Une vue (View) contient la présentation de l’interface graphique.

  • Un contrôleur (Controller) contient la logique concernant les actions effectuées par l’utilisateur.

Cette méthodologie date des années quatre-vingt, et même si elle paraît par sa date obsolète, elle est utilisée par de nombreux autres frameworks pour applications web telles que Ruby on Rails, Grails, ASP.NET MVC, Spring, Struts, Symfony, Apache Tapestry, Laravel, ou AngularJs.

L’objectif global du MVC est de séparer les aspects traitement, données et présentation, et de définir les interactions entre ces trois aspects. En simplifiant, les données sont gérées par le modèle, la présentation par la vue et la gestion de la sérialisation/désérialisation par le contrôleur.

Listons dans le détail la responsabilité de chacune des entités.

1. Le modèle

Le modèle implante les fonctionnalités de l’application. Le modèle est également responsable de la préservation...

Développement de l’application

1. Fonctionnalités

Listons les différentes fonctionnalités de l’application :

  • S’enregistrer comme utilisateur.

  • S’identifier comme utilisateur inscrit.

  • Mettre à jour ses informations personnelles : civilité et adresse(s) de livraison. 

  • Visualiser les produits disponibles à l’achat.

  • Sélectionner les produits.

  • Valider le panier et créer la facture associée.

2. Couches MVC

a. Les vues

Les vues se déduisent directement de la liste des fonctionnalités :

  • Une form conteneur de l’application TFormMain.

  • Une frame d’enregistrement/login TFrLogin.

  • Une frame de gestion du compte (civilité/adresses) TFrAccount.

  • Une frame de sélection des produits TFrItems.

  • Une frame de validation du panier TFrPurchase.

b. Les modèles

Les modèles sont des classes qui représentent des tables de la base de données.

On définit ainsi les classes :

TUser : table utilisateurs (users)

TAddress : table des adresses (addresses)

TProduct : table des produits (products)

TProductList : TList<TProduct> : ce modèle représente une liste de produit. Elle est utilisée pour stocker ce que contient le magasin à l’achat.

TPurchase : table des achats (purchases)

TProductCartList : table purchase_product qui représente la liste des objets sélectionnés pour l’achat. Il s’agit du modèle de données du panier.

c. Les contrôleurs

On définit les contrôleurs suivants :

  • TUserController

  • TAddressController

  • TProductController

  • TPurchaseController

Ils possèdent tous une référence sur la connexion à la base de données et implémentent le cas échéant un mécanisme de transaction pour assurer un rollback en cas d’erreur de persistance.

Le rollback (retour en arrière) permet de restaurer l’état de la base de données dans lequel elle se trouvait en début de transaction au cas où une erreur surviendrait lors de l’exécution des requêtes. En général, il s’agit d’une contrainte qui n’est pas respectée ou d’une erreur de syntaxe.

On définit aussi une classe TControllerBase dans laquelle...

Conclusion

En résumé, nous avons vu dans ce chapitre :

  • La méthodologie MVC qui nécessite de découper rigoureusement le code et les unités.

  • L’utilisation de l’objet TFDQuery et l’écriture de requêtes spécifiques select/insert/update

  • Le concept et l’utilisation de transaction SQL pour s’assurer du bon déroulement d’une cascade de requêtes.

  • La création d’un rapport (facture) avec les composants FastReport.