1. Architecture logique

Cette partie explique le motif de conception du système (Design pattern).
Les différentes couches du système sont :

a. Le modèle

Représente Les classes persistantes du système. Par exemple Une classe Livre.
NB: Les classes du modèle ne s’occupe pas des traitements concernant la persistance des données.

b. La vue

Concerne la forme (représentation) elle interagit avec le modèle. La vue concerne principalement la représentation des données du modèle à l'écran (ou sur tout autre périphérique de sortie).

c. Le contrôleur

Le contrôleur gère les interactions avec l'utilisateur et détermine quels traitements doivent être réalisés.

d. La persistance ou DAO (Data Access Object)

Chargée de gérer les objets persistants c'est à dire gère les interactions avec le support d'accès aux données (par exemple la base de données).

2. Schémas global

a. Requête

Représente tout appel effectué vers le serveur. Ça peut être une requête provenant du navigateur, un appel depuis un autre serveur, une requête AJAX…
Example: localhost/muuska/en/home

b. Index.php

Point d’entrée principal du système son rôle est de crée le routeur et l’initialiser.

c. Application

Classe principale du système. Elle délègue l’analyse des requêtes au Routeur.

d. Routeur

Classe permettant d’analyser les requêtes et gérer le routage des url.
Son rôle est de récupérer la requête de l’utilisateur, la formater. À partir de cette requête, détecter la langue de navigation, savoir quel sous application (Back office ou Front office, API, etc..) est concerné, de trouver le contrôleur à exécuter. Dès qu’il a trouvé le contrôleur correspondant, sont travail restant consiste à récupérer l’instance de la sous application et lui demander d’exécuter le contrôleur.

e. Sous application

Classe chargé de gérer une sous partie (Front office, Back office, API, etc…) de l’application. Lors du traitement d’une requête, c’est elle qui doit instancier le contrôleur approprié et l’exécuter.

f. contrôleur

Analyse la requête de l’utilisateur et réalise le traitement approprié puis retourne la réponse.

g. Réponse

Résultat retourné sur à l’utilisateur.

3. Diagramme de séquence du système

Résumé :

- La requête: L’utilisateur initie la requête (Exemple : localhost/muuska/en/home) vers le serveur.
- Le fichier index.php: instancie l’application et exécute sa méthode « run ».
- L’application; L’application : instancie le routeur et exécute sa méthode « run ».
- Routage: Le routeur construit le requête et initialise le flux de réponse ensuite, il lance l’analyse de la requête afin de déterminé les paramètres nécessaires à l’identification du contrôleur (Le nom du contrôleur, l’action, la langue de navigation, la sous application concerné, etc…). Une fois l’analyse de la requête terminée, le routeur doit récupérer l’instance de la sous application concerné par la requête puis demander à la sous application d’exécuter le contrôleur.
- Exécution de contrôleur; La sous application doit créer l’instance du contrôleur pour traiter la requête de l’utilisateur. Une fois l’instance du contrôleur crée, la sous application doit vérifier l’authentification puis vérifier les accès de l’utilisateur. Une fois toutes les vérifications effectuées, la sous application appellera la méthode « executeAction » du contrôleur trouvé.
- Exécution de l’action par le contrôleur: Le contrôleur effectue le traitement approprié en fonction de l’action de l’utilisateur puis appelle la méthode « outputResult » pour le retour de la réponse.