---

Répartition du Git

La racine de notre git est composée de deux dossiers essentiels au projet:

src : Toute la partie code de l'application (ne contient que le serveur TypeScript à l'heure actuelle sans l'implémentation du service de mail)

doc : Documentation de l'application vous pourez y retrouvez nos différents Schéma et divers documentation

Contexte  

Ce projet consiste en une API web reliée à une base de donnée SQLite permettant d'avoir accès à différentes données relatives à League of Legends, par exemple les différents champions. Une application MAUI est également disponible.  

Get Started

• Prérequis

Vous devez disposer d'un environnement Asp.net Core Entity Framework Core 2.+ configuré.

• Installation

Tout d'abord, si ce n'est pas fait, clonez le dépôt de la branche master, pour cela copiez le lien URL du dépôt git : git clone https://codefirst.iut.uca.fr/git/arthur.valin/League-of-Legends_Project.git

• Comment lancer le projet ?

Ensuite, dans un terminal, assurez-vous que vous possédez les dépendances nécessaires, pour cela : ...

👉 Solution de l'application

Fonctionnement

Le projet est entièrement développé en .NET, principalement .NET6 mis-à-part le client MAUI développé en .NET7. La partie base de données en gérée par l'ORM Entity Framework. L'API permet d'effectuer des opérations CRUD sur les données.

Schéma général du projet

---

Le client effectue des requêtes à l'API qui expose différentes routes (/champions, /runes...). Ces routes sont gérées par des contrôleurs. Ces requêtes peuvent contenir un corps en json qui sera mappé en une classée métier. Selon la requête, cette classe métier sera ensuite remappé en une entité qui sera ensuite persistée en base de données. L'API renvoie ensuite une réponse au client.

L'API effectue des requêtes côté base de données grâce à un DBManager, qui contient les différents oppérations permettant d'accéder et d'altérer les données.

Schéma des différentes tables présentes au sein de la base de données

---

• Comment ça marche au niveau du code ?

Versionning

Notre API REST est atteignable à ces deux URIs ci-dessous :

• V1 - Ne dois pas être contactée et ne dispose pas de toutes les fonctionnalités - V1

• V2 - C'est sur cette URI que il faut contacter l'API - V2

Chaîne de connexion

Nous injectons la chaîne de connexion depuis appsettings.json, le fichier de configuration de l'API. Il est ainsi possible de choisir un système de gestion de base de données différent en production qu'en développement.

Nous avons cependant choisis SQLite pour ces deux environnements. L'idée est de faciliter un éventuel changement de système.

RoadMap

Récapitulatif de notre avancée sur le projet : 👇

Où nous en sommes ❔❕ ([x] &nbsp: réalisé, ⚠️ presque abouti, ❌ non commencé )

ℹ️  ...

•  

•  

• Toutes les données qu'expose l'API sont des DTOs mappés par ces mapper Mappeur.

•  

• Les réponse de l'API respectent les normes de code de retour. Vous pouvez retrouver ici un tableau les récapitulant Code de Retour.

•  

•  

•  

•   ![Versioning]

•  

• Toutes les opérations crud on été réalisées avec l'inclusion de réponse HATEOS.

•  

•  

:warning

• Etant donné que l'on ne pouvait pas faire compiler le client sans les dépendances, nous avons fait le client en console vous pouvez le retrouvez ici - De plus étant donné que le model client est le même que ceului api, il était logique d'utiliser les même mappeur et les DTO c'est pour sa que le cient à la référence au Mappeur API et au DTO API Bibliothèque du Client http .

•  
•  

• Minimal Sécurité juste sur les actions du Controller de rune page il faut faire attention a inculure la key : "ViveC#" dans votre request . (swgagger à été configuré pour l'autification il vous suffit de cadena pour vous authentifier) .

<>

Tests

Des tests unitaires ont été réalisés via xUnit, notamment sur les entités et le DBManager.

Auteurs

Arthur Valin - arthur.valin@etu.uca.fr - arthur

David d'Almeida - david.d_almeida@etu.uca.fr - david

© PM2