Dev du 23/10/2017

Commit : 1d3c80045cc77d5c914de1262f29725fb1feef57

Mise à jour des tests de la base de données pour prendre en compte l'architecture réelle de la table des utilisateurs

Commit : 07cbf18e1b9df118e4766db679b36db939536232

Création du repository de base (à utiliser si aucun repository spécifique à l'entité)
Création des tests unitaire du repository
Création d'un fichier user.sql pour mettre en place la table user de la BDD de test
Correction d'un bug dans la gestion des requêtes de sélection et dans l'entité User

Commit relativement important ainsi que le prochain, car c'est la création et mise en place du système de Repository.
Ce système permet d'avoir des fonctions communes à toutes le entités devant lire dans la base.
Chaque entité pourra à terme avoir son propre repository avec donc soit les fonctions communes (héritage de Repository) soit des fonctions spécifiques, ceci permettant de créer des requêtes supplémentaires.

Petite question: c'est quoi héritage de Repository?

En programmation dite "Programmation Orientée Objet" ou POO, on a plusieurs notions. Pour simplifier, la POO, c'est le principe d'avoir un objet (une classe on appel ça), contenant des fonctions qui y sont propre (des méthodes pour le nom exacte ), cela permet d'éviter que des fonctions interfères les unes avec les autres.

En programmation, une fonction est unique, ainsi une fonction bonjour par exemple, ne peut être redéfinie, il faut alors qu'on trouve un autre nom pour la fonction qui fait une chose similaire. Avec un objet, on s'embête pas, c'est l'objet qui doit avoir un nom différent, à l'intérieur on peut avoir une fonction avec le même nom que la fonction d'un autre objet.

En gros, il faut voir les classes (ou objets ) comme une voiture, la voiture est un objet, dedans on a les roues, les essieux, la boîte de vitesse, le cardan, le moteur, le radiateur etc. (je détaillerais pas toutes les pièces d'une voiture ), tout ça se sont des éléments du véhicule. Donc Voiture est un objet (une classe), et dedans on a des variables (propriétés pour une classe) qui sont : roues, moteur etc.

Mais nous avons aussi des fonctions : avancer, reculer, tournerAGauche, [/b]tournerADroite[/b] etc.

Le camion a la même chose, mais différemment : les pièces sont pas disposées pareils, le moteur va pas à la même vitesse etc., du coup les quatre fonctions vont travailler différemment. Au final, l'objet camion a donc son travail propre et pareil pour l'objet voiture.


Maintenant qu'est-ce que l'héritage ? Ben l'héritage en programmation, c'est un objet qui dépend d'un autre objet et qui en obtient toutes les propriétés et méthodes. Par exemple, le camion et la voiture sont des véhicules donc on pourrait avoir un objet []Vehicule[/b], ce dernier aurait donc les éléments communs comme le moteur, les roues etc. ainsi que les fonctions communes (avancer, reculer etc.).

Ces fonctions auraient donc leur propre "implémentation" c'est à dire un code indiquant ce quelles doivent faire, permettant donc à l'objet "héritant" (l'enfant de l'objet Vehicule dans l'exemple), d'avoir déjà un fonctionnement de base. Après rien n'empêche cet enfant d'avoir son propre fonctionnement, la fonction appelée sera alors celle de l'enfant et non celle du parent.

En revanche, si la fonction est absente de l'enfant, c'est directement celle du parent qui est utilisée, mais l'enfant peut aussi définir son propre fonctionnement ET utiliser celle du parent (nous devons alors l'indiquer spécifiquement).


Ici, dans le cas du site, l'objet Repository, fournis actuellement deux fonctions communes :
find et findAll, la première va récupérer une ligne de la base de donnée suivant la table spécifiée et donc les éléments de cette table (on lui donne donc à l'objet, un autre objet qui est l'entité ainsi sa définition) suivant le numéro d'identification indiqué dans les paramètres de la fonction.
La seconde fonction elle, va aller chercher l'intégralité des lignes de la base de données, de la table concernée (sans aucun filtre).


Ainsi, l'objet User qui est une entité, peut ou non disposer de son objet User héritant de Repository. Si cet objet est inexistant, le système cherchera Repository directement et appellera donc les fonctions de ce dernier.

Si par contre le repository User existe, ce dernier aura ses fonctions propres (par exemple des requêtes personnalisées), mais aussi les fameux find et findAll de l'objet parent Repository.


Le principe du repository au niveau d'un site internet, c'est de pouvoir faire des requêtes dans la base de données qui sont déjà prêtes voir qui ont déjà était faites et qui sont génériques.
En effet, le repository spécifique à l'entité fera des requêtes spécifiques à la table concernée, comme par exemple aller chercher un utilisateur et afficher le nom du groupe dont il appartient (on a alors là une "jointure" c'est à dire que la requête travaille sur deux tables selon un élément commun aux deux : le numéro d'identification du groupe, d'un côté c'est l'identifiant de la table des groupes, de l'autre c'est le numéro d'identifiant du groupe associé à l'utilisateur ; les deux étant identique, c'est en quelque sorte un filtre que nous faisons entre deux tables de la base).
Mais le repository de base lui, va travailler que sur la table qu'on lui indique et va permettre certaines choses de suite comme aller chercher un utilisateur particulier ou récupérer toute la liste des utilisateurs.


A terme ici, le repository de base, fournira la possibilité de filtre par le champ (ou les champs) qu'on désire, avoir toute la liste ou que le premier élément trouvé etc.