Mettre en place les Models et Managers
Les Models
Lorsque vous travaillez avec le MVC, vos Models sont les classes qui représentent les tables de votre base de données. En prgrammation lorsqu'une clase sert à représenter en code des données présentes en base, on appelle ça un DAO (Data Access Object), vous en trouverez dans pratiquement tous les frameworks et design patterns.
Dans le MVC, on les appelle donc les Models (c'est eux le M de MVC).
Représenter une table
Imaginons que vous avez une table users en base de données qui représente les utilisateurs d'une bibliothèque.
La table pourrait ressembler à ceci :
nom de la colonne | type de la colonne |
|---|---|
id | int |
firstName | varchar(255) |
lastName | varchar(255) |
varchar(255) | |
password | varchar(255) |
Le Model qui correspond à la table users devra être une classe qui correspond à la structure de la table.
Ici, nous aurions donc :
J'ai bien tous les attributs présents dans la table, initialisés dans le constructeur, et j'ai ajouté mes getters et setters.
Représenter une relation simple
Imaginons que les usages de notre bibliothèque aient des cartes pour emprunter des livres, stockées dans une table cards.
nom de la colonne | type de la colonne |
|---|---|
id | int |
user_id | int Foreign Key |
expiration | datetime |
Pour représenter la relation entre la Card et le User, nous allons utiliser la composition (une classe est l'attribut d'une autre) :
Représenter une relation complexe
Imaginons maintenant qu'avec leurs cartes, nos utilisateurs emprunte des livres, nous allons avoir besoin de pouvoir suivre où sont quels livres. Dans la base de données nous aurons donc eux nouvelles tables : books et cards_books.
la table books
nom de la colonne | type de la colonne |
|---|---|
id | int |
title | varchar(255) |
author | varchar(255) |
la table card_books
nom de la colonne | type de la colonne |
|---|---|
card_id | int FK |
book_id | int FK |
Pour représenter cette relation complexe dans notre classe, nous allons encore utiliser la composition. Mais au lieu d'avoir en attribut une unique instance de classe, nous aurons en attribut, un tableau d'instances de classes.
la classe Book
Modifions la classe Card
Vous avez donc ici des exemples pour les trois principaux cas de figure que l'on rencontre dans les Models. Maintenant il ne nous reste plus qu'à les faire remplir / sauvegarder par la base de données.
Mettre en place les Managers
Les Managers (parfois appellés Repositories) sont des classes dont les méthodes correspondent aux requêtes que vous voulez effectuer sur la base de données. Vous devez avoir un Manager par Model.
AbstractManager
Tous vos Managers auront besoin d'une connexion à la base de données, vous allez donc placer celle-ci dans une classe abstraite AbstractManager dont hériteront tous vos Managers.
Le CardManager
Je vais montrer ici l'exemple du CardManager parce que c'est lui qui aura les requêtes les plus complexes, mais le même principe s'applique pour tous les managers.
Un Manager doit au minimum avoir 5 méthodes publiques :
createqui permet d'insérer en base de donnéesupdatequi permet de mettre à jour en base de donnéesdeletequi permet de supprimer de la base de donnéesfindOnequi permet de trouver une entrée dans la base de donnéesfindAllqui permet de trouver toutes les entrées de la base de données
Les méthodes create, update et delete en revanche ne changent pas de celles que vous connaissez déjà avec les cours et exercices du j4 etles cours et exercices du J5.
Exemples sur une classe plus simple
Imaginons que dans mon BookManager je veux pouvoir effectuer ces 5 opérations pour les Books :