# Projet d'Entity FrameWork et Consomation et Développement de services
Notre projet à pour objectif la liaison entre une base de donnée et un client, par l'utilisation d' ``EntityFramework`` et d'une ``API`` C# créé par nous même.
implémentation des runes et skins (1 table -> pas de relation)
* Exo5 : :heavy_check_mark:
Relation entre champion et skin (OneToMany)
* Exo6 : :heavy_check_mark:
Relation entre Champion, RunePage et Rune (ManyToMany)
> La relation entre Rune et RunePage à été simplifiée par manque de temps, il ne s'agit donc pas d'un dictionaire mais d'un OneToMany.
* Exo7 : :heavy_check_mark:
mapping entre model et entité (intégration de qualité)
(en 1 table et avec relations)
* Exo8 : :heavy_exclamation_mark:
Ajouter le paterne UnitOfWork (rollback en cas de probleme sur les transaction)
---
#### Diagramme d'architechture :
Le schéma ci-dessus décris l'architecture finale que doit avoir le projet,
Tout en haut, la partie client est composé du client MAUI et et du client Console, ceux-ci permettent l'affichage des ressources, l'utilisation de l'architecture et donc de tester si tout le projet fonctionne. Celui-ci utilise le HTTPDataManager qui lui permet d'effectuer les requêtes à l'API afin de récupérer les données. Il hérite de IDataManager et peux donc être remplacé par EFDataManager, court-circuitant ainsi l'API ou par StubLib, n'utilisant pas l'API et l'EF. Le DataManager utilise l'une des extensions mapper pour convertir les objets DTO en Model.
> On indique aux client d'utiliser le HttpDataManager :
En second, la partie API, celle-ci s'occupe de recevoir les requêtes et de renvoyer les objet en conséquent. Dans l'implémentation idéale, l'API utilise l'EFDataManger pour faire appel aux données stockés en base de données. Il hérite lui aussi de IDataManager mais ne peut être remplacé que par le StubLib.Il utilise lui aussi des extensions mapper pour convertir les objets Entity en Model.
> On indique à l'API d'utiliser le EFDataManager :
Corentin R
2 years ago
