lmasi/webzine
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Documentation: relecture, ajout de la conclusion. Dossier de configuration complété.

Browse Source
This commit is contained in:
josephine.vetu
2026-04-09 00:19:46 +02:00
parent c676019040
commit 267a50f053
8 changed files with 170 additions and 132 deletions
Download Patch File Download Diff File Expand all files Collapse all files

80
Webzine.Documentation/Installation/equipe 1 - dossier de configuration.md
View File

@@ -1,4 +1,4 @@
# Dossier de configuration — Projet Webzine
# Dossier de configuration - Projet Webzine
**Équipe 1**
**Formation :** Développement .NET niveau 1 / Dr1-P4
@@ -12,6 +12,7 @@
| ----- | ------------- |
| 25/03 | Clément Bobin |
| 31/03 | Joséphine Vetu |
| 08/04 | Joséphine Vetu |
---
@@ -24,7 +25,7 @@ Avant de lancer l'application, assurez-vous d'avoir installé les outils suivant
| .NET SDK | 10.0 | https://dotnet.microsoft.com/download |
| Node.js (optionnel, pour outils front) | 18+ | https://nodejs.org |
| Git | 2.x | https://git-scm.com |
| Un IDE | Visual Studio 2022+ ou Rider | — |
| Un IDE | Visual Studio 2022+ ou Rider | - |
---
@@ -80,25 +81,71 @@ Ouvrir `Webzine.sln`, sélectionner le profil `https` ou `http`, puis lancer ave
## 5. Configuration applicative
Le fichier principal de configuration est `Webzine.WebApplication/appsettings.json` :
La configuration de l'application est répartie sur plusieurs fichiers `appsettings` selon l'environnement.
### `appsettings.json` - configuration commune
Ce fichier contient les paramètres partagés entre tous les environnements :
- **Logging** : niveau `Information` par défaut, `Warning` pour ASP.NET Core, et `Debug` pour la couche repository afin de tracer les requêtes.
- **Webzine** : paramètres d'affichage (nombre de chroniques et de titres sur la page d'accueil, nombre de lignes dans les vues d'administration). Ces valeurs sont injectées via `IConfiguration` et modifiables sans recompilation.
- **ConnectionStrings** : chaînes de connexion pour SQLite (dev) et PostgreSQL (prod). L'application bascule de l'une à l'autre selon la valeur de `Repository`.
- **SpotifySeeder** : paramètres de l'import Spotify - credentials, marché cible, genres musicaux, et limites de volumétrie (artistes par genre, albums par artiste, titres par album, commentaires par titre).
- **EfPerformance** : seuil en millisecondes au-delà duquel une requête Entity Framework est considérée comme lente (60 ms par défaut).
### Configuration par environnement
#### Développement - `appsettings.Development.json`
```json
{
"Webzine": {
"NombreDerniereChronique": 3,
"NombreDeTopTitres": 3
"Seeder": "Spotify",
"Repository": "Db",
"SpotifySeeder": {
"ClientId": "",
"ClientSecret": ""
}
}
```
| Propriété | Type | Description | Valeur par défaut |
| ------------------------- | ---- | -------------------------------------------------------------------------------- | ----------------- |
| `NombreDerniereChronique` | int | Nombre de chroniques affichées sur la page d'accueil (section "Derniers titres") | 3 |
| `NombreDeTopTitres` | int | Nombre de titres affichés dans le bloc "Titres les plus populaires" | 3 |
#### Production - `appsettings.Production.json`
Ces valeurs sont injectées dans `AccueilController` via `IConfiguration` et peuvent être modifiées sans recompilation.
```json
{
"Seeder": "Local",
"Repository": "Db",
"SpotifySeeder": {
"ClientId": "",
"ClientSecret": ""
}
}
```
### Valeurs acceptées
Les propriétés `Seeder` et `Repository` correspondent aux enums suivants :
```csharp
public enum SeederType
{
Local, // Données mockées en mémoire
Spotify, // Données récupérées depuis l'API Spotify
}
public enum RepositoryType
{
Local, // Données en mémoire (pas de base de données)
Db, // Base de données (SQLite en dev, PostgreSQL en prod)
}
```
| Propriété | Type | Valeurs acceptées | Description |
|---|---|---|---|
| `Seeder` | `SeederType` | `Local`, `Spotify` | Source des données au démarrage |
| `Repository` | `RepositoryType` | `Local`, `Db` | Mode d'accès aux données |
| `SpotifySeeder.ClientId` | string | - | Identifiant de l'application Spotify |
| `SpotifySeeder.ClientSecret` | string | - | Secret de l'application Spotify |
Pour l'environnement de développement, les surcharges se font dans `appsettings.Development.json`.
---
@@ -175,10 +222,17 @@ Cela désactive les pages d'erreur détaillées et active les optimisations de p
## Ajout du pre-commit
Les fichiers présents dans le dossier git_hooks sont à copier dans le dossier caché .git.
```bash
git config core.hooksPath Webzine.Documentation/git_hooks
```
Les fichiers présents dans le dossier git_hooks sont les suivants:
Le pre-commit reformatte le code à chaque commit.
Le commit-msg vérifie si le message du commit respecte bien les conventions du cahier des charges:
- le message référence un ticket
- le message termine par un point
- le message doit faire au moins 10 caractères
Il n'est pas nécessaire de les copier et de les ajouter au dossier caché .git.
La commande ci-dessus suffit.

46
Webzine.Documentation/Rapport/equipe 1 - 1.Introduction.md
View File

@@ -1,4 +1,4 @@
# Rapport d'équipe — Projet Webzine
# Rapport d'équipe - Projet Webzine
**Équipe 1**
**Formation :** Développement .NET niveau 1 / Dr1-P4
@@ -8,13 +8,14 @@
## Table des modifications
| Date | Auteur |
|------|--------|
| 04/03 | Loïc Masi |
| 05/03 | Loïc Masi |
| 06/03 | Loïc Masi |
| 25/03 | Clément Bobin |
| Date | Auteur |
| ----- | -------------- |
| 04/03 | Loïc Masi |
| 05/03 | Loïc Masi |
| 06/03 | Loïc Masi |
| 25/03 | Clément Bobin |
| 06/04 | Joséphine Vetu |
| 08/04 | Joséphine Vetu |
---
@@ -22,33 +23,6 @@
Ce rapport présente le travail réalisé par l'équipe 1 dans le cadre du projet Webzine, une application web de chroniques musicales développée avec ASP.NET Core MVC sur .NET 10. L'objectif du projet était de construire une plateforme permettant de gérer et consulter des artistes, des titres, des styles musicaux et des commentaires, avec un espace d'administration dédié.
Ce document ne revient pas sur le cahier des charges ni sur les fonctionnalités de l'application — ces éléments sont déjà connus de tous. Il s'attache plutôt à décrire comment l'équipe s'est organisée, ce qui a bien fonctionné, ce qui a posé problème, et les enseignements que l'on peut en tirer.
Ce document ne revient pas sur le cahier des charges ni sur les fonctionnalités de l'application - ces éléments sont déjà connus de tous. Il s'attache plutôt à décrire comment l'équipe s'est organisée, ce qui a bien fonctionné, ce qui a posé problème, et les enseignements que l'on peut en tirer.
---
---
**Lo<4C>c Masi** :
04/03 :
- Cr<43>ation de 'AccueilController'
- Cr<43>ation de la fonction Index() -> afficher l'accueil du webzine
- Ajout de la vue 'Views/Accueil/Index.cshtml'
- Mise en place d'un Header dans 'Views/Shared/_Header.cshtml'
- Mise en place de la Sidebar dans 'Views/Shared/_Sidebar.cshtml'
05/03 :
- Mise en place de fausse donn<6E>es dans 'Webzine.Repository' <20> l'aide de Faker
- Ajout du ViewModel pour afficher les informations n<>cessaire sur la page d'accueil
- Adaptation de quelques <20>l<EFBFBD>ments sur la page (Bootstrap)
- Mise en place du parametrage du nombre d'elements a afficher sur la page dans appsettings
- Modifiaction du header pour ajouter le Dropdown (Administration) et ajout de quelques redirections
06/03 :
- R<>cup<75>ration des modifications depuis 'dev'
- Ajout des redirections vers les pages 'Administration'
- Adaptation du layout principal pour adaptation entre public et administration
- Ajout du Footer (sur toutes les pages)
-
---
Les chapitres sont divisés en fichiers, comme demandé dans le cahier des charges.

46
Webzine.Documentation/Rapport/equipe 1 - 2.Organisation Dev.md
View File

@@ -1,4 +1,4 @@
# Rapport d'équipe — Projet Webzine
# Rapport d'équipe - Projet Webzine
**Équipe 1**
**Formation :** Développement .NET niveau 1 / Dr1-P4
@@ -11,18 +11,19 @@
Chaque développeur s'est vu attribuer une responsabilité principale sur l'une des entités du domaine : `Artiste`, `Titre`, `Commentaire`, `Style`. Cette segmentation verticale a permis à chacun de maîtriser son périmètre tout en contribuant à l'ensemble. En pratique, les tâches couvraient systématiquement les trois couches : entité (avec ses annotations de validation), repository (logique de données), et contrôleur/vue (rendu web).
Concernant les rôles :
- Tout le monde a pu suivre "le cycle de la vie", ce qui a favorisé une bonne compréhension commune du modèle de données, de la factory aux repository.
- Au fil du projet, chaque personne a pu se spécialiser dans un domaine particulier. Le reste de l'équipe était tenu au courant à l'aide de TOS réguliers.
- Tout le monde a pu suivre "le cycle de la vie" d'une entité, ce qui a favorisé une bonne compréhension commune du modèle de données, de la factory aux repository.
- Au fil du projet, chaque personne a pu se spécialiser dans un domaine particulier (voir la partie "Répartition des tâches"). Le reste de l'équipe était tenu au courant à l'aide de TOS réguliers.
L'équipe de développement est composée de cinq membres:
| Membre | Rôle principal | Domaine |
|---|---|---|
| Joséphine | Cheffe de projet & développeuse | Dev |
| Clément B | DevOps (CI/CD) | Dev |
| Loïc | Développeur / intégration BDD | Dev |
| Baptiste | Développeur | Dev |
| Mathys | Ingénieur système et réseau | Ops |
| Membre | Rôle principal | Domaine |
| --------- | ------------------------------- | ------- |
| Joséphine | Cheffe de projet & développeuse | Dev |
| Clément B | DevOps (CI/CD) | Dev |
| Loïc | Développeur / intégration BDD | Dev |
| Baptiste | Développeur | Dev |
| Mathys | Ingénieur système et réseau | Ops |
Mathys étant le seul membre côté ops, il a travaillé en parallèle de l'équipe de développement tout en étant intégré aux dailys et aux jalons.
@@ -41,27 +42,27 @@ Chaque jalon a été ponctué d'une **code review** encadrée, qui a joué un r
### Démonstrations et supports
Les démonstrations de fin de jalon ont imposé un moment de convergence collective. Le 26 et 27 mars, la préparation du support de démo (sur Canva) a mobilisé l'ensemble de l'équipe. Ces moments ont aussi servi à clarifier les livrables attendus — notamment côté ops, où les attendus du jalon 2 (dashboard Grafana, schéma infra, HTTPS) ont été précisés lors du daily du 26 mars.
Les démonstrations de fin de jalon ont imposé un moment de travail collectif. La préparation du support de démo (sur Canva) a mobilisé l'ensemble de l'équipe.
---
## Répartition des tâches
### Joséphine — Cheffe de projet & développeuse
### Joséphine - Cheffe de projet & développeuse
Joséphine a endossé un double rôle tout au long du projet. D'un côté, elle a assuré la gestion de projet : rédaction des tickets, priorisation, animation des dailys, compte-rendus et revue de code. De l'autre, elle a contribué activement au développement : page artiste, repository Artiste, pagination, correction transversale des erreurs de controllers et de HTML.
Ce double rôle a représenté une charge de travail importante, notamment en fin de jalon où la gestion de projet et les corrections de bugs se sont superposées.
### Clément — Développeur mais surtout DevOps
### Clément - Développeur mais surtout DevOps
Clément a posé les bases de l'architecture : initialisation du dépôt Git, mise en place du patron MVC, création des factories et des controllers de base. Il a ensuite pris en charge les repositories Style et Titre, la mise à jour de l'API, la rédaction de la documentation, et la CI/CD côté tests d'endpoints.
### Loïc — Développeur / intégration BDD
### Loïc - Développeur / intégration BDD
Loïc a développé la page d'accueil dès le jalon 1, en y intégrant Bootstrap, les fausses données via Faker, puis le ViewModel. Au jalon 2, il a pris en charge la configuration de la base de données SQLite, la création du seeder, et le CRUD sur les entités Style et Artiste. Il a également travaillé sur l'optimisation de la recherche et l'intégration de l'API Spotify en jalon 3.
### Baptiste — Développeur fonctionnel
### Baptiste - Développeur fonctionnel
Baptiste a développé les fonctionnalités liées aux commentaires (modèle, vue, controller, repository) et aux styles côté administration. Il a aussi contribué à la correction des bugs. En jalon 3, il a réalisé la refactorisation des routes dans une classe `RouteConfiguration.cs` et l'implémentation d'un middleware de logging.
@@ -76,6 +77,7 @@ L'ensemble du code source, des tickets et de la documentation a été centralis
Le travail a été découpé en branches Git par fonctionnalité. Les nommages utilisés reflétaient généralement l'entité ou la fonctionnalité concernée (ex : `feat/artiste-controller`, `feat/titre-entity`, `feat/administration-dashboard`). Les merges ont été faits via des pull requests revues par au moins un autre membre de l'équipe.
Cette pratique a contribué à maintenir la qualité du code, mais elle a également constitué un **goulot d'étranglement**. Les reviews de code ont pris beaucoup de temps. Il y a eu quelque fois un volume important de PR ouvertes simultanément. L'équipe n'avait pas défini en amont de règles sur la taille maximale des PR ou les délais de review.
A partir du jalon 3, les revues de code ont été réparties entre chaque membre de l'équipe.
### Qualité du versioning
@@ -83,18 +85,10 @@ La discipline de versioning s'est améliorée au fil du projet. En jalon 1, Bapt
### Décisions d'architecture en daily
Un point notable de l'organisation est que plusieurs décisions techniques structurantes ont été prises *collectivement*, pendant les dailys en demandant à l'intervenant, plutôt qu'en amont lors d'une phase de conception :
Un point notable de l'organisation est que plusieurs décisions techniques structurantes ont été prises _collectivement_, pendant les dailys en demandant à l'intervenant, plutôt qu'en amont lors d'une phase de conception :
- La stratégie de double repository (`repositorydb` pour la prod PostgreSQL, `repositorylocal` pour le dev SQLite) — décidée le 25 mars
- La stratégie de double repository (`repositorydb` pour la prod PostgreSQL, `repositorylocal` pour le dev SQLite) - décidée le 25 mars
- Le découpage de `Program.cs` en sous-classes pour éviter un fichier trop long
- Le remplacement du ViewModel Dashboard par un DTO pour respecter la séparation des couches — identifié le 1er avril
- Le remplacement du ViewModel Dashboard par un DTO pour respecter la séparation des couches - identifié le 1er avril
Cette approche a permis de s'adapter aux contraintes au fur et à mesure, mais elle a aussi engendré du refactoring qui aurait pu être évité avec une conception initiale plus approfondie.
---
## Montée en compétences
La progression de l'équipe est visible tout au long du projet. Dès les premiers jours, l'architecture MVC est comprise. L'équipe se familiarise avec Bootstrap et les bonnes pratiques Git en cours de jalon 1. Loïc et Clément explorent Faker pour les données de test dès les premiers jours.
En jalon 2, l'équipe maîtrise suffisamment l'architecture pour introduire la couche repository et abstraire l'accès aux données. En jalon 3, les sujets abordés sont les middleware, la CI/CD, les différents seed et les hooks Git.

4
Webzine.Documentation/Rapport/equipe 1 - 3.Organisation DevOps.md
View File

@@ -1,4 +1,4 @@
# Rapport d'équipe — Projet Webzine
# Rapport d'équipe - Projet Webzine
**Équipe 1**
**Formation :** Développement .NET niveau 1 / Dr1-P4
@@ -35,7 +35,7 @@ La mise en place de la CI/CD a été un travail conjoint entre Clément et Mathy
### Une communication sur les livrables ops insuffisante en amont
Durant le deuxième jalon, les développeurs ne savaient pas exactement ce qui était attendu côté ops pour la livraison du jalon 2. Les attendus — dashboard Grafana, schéma d'infrastructure, passage en HTTPS — ont été clarifiés pendant le daily, à deux jours de la démo. Ce manque d'anticipation sur les livrables ops a pu créer de la pression inutile en fin de sprint.
Durant le deuxième jalon, les développeurs ne savaient pas exactement ce qui était attendu côté ops pour la livraison du jalon 2. Les attendus - dashboard Grafana, schéma d'infrastructure, passage en HTTPS - ont été clarifiés pendant le daily, à deux jours de la démo. Ce manque d'anticipation sur les livrables ops a pu créer de la pression inutile en fin de sprint.
## Bilan

11
Webzine.Documentation/Rapport/equipe 1 - 4.Problemes techniques.md
View File

@@ -1,4 +1,4 @@
# Rapport d'équipe — Projet Webzine
# Rapport d'équipe - Projet Webzine
**Équipe 1**
**Formation :** Développement .NET niveau 1 / Dr1-P4
@@ -25,11 +25,12 @@ Nous avons pourtant passer en revue chaque PR. Ces corrections ont permis d'amé
C'est probablement le chantier le plus difficile du jalon 2. Au jalon 1, les données étaient instanciées directement dans les controllers via des classes factory. Ça fonctionnait pour afficher les vues, mais tout était couplé : il était impossible de connecter une vraie base de données sans tout réécrire.
La migration vers des repositories a impliqué plusieurs changements simultanés :
- extraire la logique de données,
- créer des interfaces,
- reconfigurer `Program.cs` pour gérer l'injection de dépendances.
Cette dernière partie a été la plus difficile à appréhender — les cycles de vie des services (`Singleton`, `Scoped`, `Transient`) et la façon dont ASP.NET Core résout les dépendances à l'exécution n'étaient pas évidents au départ.
Cette dernière partie a été la plus difficile à appréhender - les cycles de vie des services (`Singleton`, `Scoped`, `Transient`) et la façon dont ASP.NET Core résout les dépendances à l'exécution n'étaient pas évidents au départ.
La coexistence de deux environnements (SQLite en dev, PostgreSQL en prod) a ajouté une couche de complexité supplémentaire : il fallait deux implémentations concrètes des mêmes interfaces et conditionner leur enregistrement dans `Program.cs` selon l'environnement.
@@ -64,9 +65,3 @@ Ce type d'erreur arrive quand les responsabilités des différentes couches ne s
La CI/CD mise en place par Clément et Mathys teste tous les endpoints de l'application et mesure leurs temps d'exécution. C'est un choix pertinent pour surveiller les performances, mais lors de sa mise en place initiale, chaque exécution du pipeline rendait Gitea inutilisable pendant une dizaine de secondes.
Pour une équipe dont tout le code et tous les tickets reposent sur cette instance, c'était bloquant. Le problème venait du fait que les dépendances étaient retéléchargées à chaque run. Les mettre en cache a résolu le problème.
C'est une pratique standard de CI/CD que nous aurions dû anticiper. Plus globalement, faire tourner le runner CI/CD sur la même machine que Gitea n'est pas idéal : les ressources sont partagées, et un pipeline gourmand peut dégrader l'ensemble des services.
### L'incident HTTPS sur Gitea
Le 25 mars, le passage de Gitea en HTTPS a causé une perte d'accès temporaire au dépôt, gérée seul par Mathys. Si l'incident a été résolu rapidement, une panne plus longue aurait pu bloquer toute l'équipe. Le fait qu'une seule personne administre l'ensemble de l'infrastructure crée ce type de fragilité.

29
Webzine.Documentation/Rapport/equipe 1 - 5.Conclusion.md
View File

@@ -1,4 +1,4 @@
# Rapport d'équipe — Projet Webzine
# Rapport d'équipe - Projet Webzine
**Équipe 1**
**Formation :** Développement .NET niveau 1 / Dr1-P4
@@ -6,20 +6,21 @@
---
### Progrès établis jalon 1
# Conclusion
- Architecture MVC correctement structurée avec séparation claire entre entités, repositories, et web
- Système de tests unitaires fonctionnel sur toutes les entités (ArtisteTests, CommentaireTests, StyleTests, TitreTests)
- Interface d'administration complète visuellement (CRUD artistes, titres, styles, commentaires)
- Recherche full-text opérationnelle sur les titres et styles
- Injection de dépendances configurée proprement pour le repository de titres
- Logging NLog en place et fonctionnel
- StyleCop configuré sur tous les projets
Ce projet a été très formateur. Nous avons pour la première fois travaillé avec un **cahier des charges** précis, ce qui nous a obligés à lire attentivement les consignes, à poser des questions, et à ne pas partir dans des directions non demandées. La présence régulière des intervenants a également joué un rôle : savoir que le travail serait relu et évalué de près nous a poussés à être plus rigoureux sur la qualité du code, la documentation et les pratiques Git.
Sur le plan technique, la **montée en compétences** a été réelle. En trois semaines, nous sommes passés de données mockées en dur dans les controllers à une application connectée à une base de données, avec des repositories abstraits, une CI/CD fonctionnelle, un middleware de logging et un seeder alimenté par une API externe. Ce n'était pas acquis en début de projet.
Pour ma part (Joséphine), c'était la première fois que j'assumais un rôle de **cheffe de projet**. Je l'ai pris très au sérieux, en essayant de structurer le travail de l'équipe sans le surcharger, de maintenir une vision d'ensemble tout en continuant à contribuer au développement. Ce dernier point a été compliqué, j'ai fait autant de revue de code que de développement pur.
Ce qui m'importait autant que les livrables, c'était que chacun se sente bien dans l'équipe - nous avions des profils très différents, des niveaux différents, et il fallait que tout le monde puisse avancer à sa façon sans se sentir laissé de côté. Je pense que nous y sommes globalement arrivés.
Il reste des choses que nous ferions différemment : une conception initiale plus approfondie, des règles de contribution définies dès le départ, et une communication plus formalisée entre dev et ops.
### Points qui permettraient d'améliorer le Webzine
- Implémenter les interfaces de repository manquantes et brancher tous les contrôleurs sur l'injection de dépendances
- Ajouter Entity Framework Core pour la persistance réelle (le `DbEntityRepository` attend d'être complété)
- Utiliser des ViewModels typés dans les actions POST d'administration pour bénéficier de la validation automatique
- Mettre en place la pagination sur la liste des titres (le bouton "Titres plus anciens" est présent dans la vue mais non fonctionnel)
- Ajouter des tests d'intégration en complément des tests unitaires sur les entités
**Performance du dashboard**
Le dashboard d'administration effectue plusieurs requêtes `COUNT` distinctes au chargement, ce qui le rend plus lent que le reste de l'application. Des optimisations ont été apportées en cours de projet, mais elles pourraient être encore plus efficaces.
**Authentification et gestion des droits**
L'interface d'administration est accessible sans authentification. Mettre en place un système de connexion avec des rôles (administrateur / visiteur) rendrait l'application utilisable en conditions réelles. Ce point n'était néanmoins pas demandé dans le cahier des charges.

34
Webzine.Documentation/Rapport/equipe 1 - Annexes.md
View File

@@ -1,4 +1,4 @@
# Rapport d'équipe — Projet Webzine
# Rapport d'équipe - Projet Webzine
**Équipe 1**
**Formation :** Développement .NET niveau 1 / Dr1-P4
@@ -14,7 +14,7 @@
Webzine.Entity/ → Entités du domaine (Artiste, Titre, Style, Commentaire)
Webzine.Entity.Tests/ → Tests unitaires sur les entités
Webzine.Repository.Contracts/ → Interfaces des repositories
Webzine.Repository/ → Implémentations (Local, Db — partiel)
Webzine.Repository/ → Implémentations (Local, Db - partiel)
Webzine.Business/ → Couche métier (non utilisée dans ce sprint)
Webzine.Business.Contracts/ → Interfaces métier
Webzine.EntitiesContext/ → Contexte EF (non utilisé)
@@ -22,22 +22,22 @@ Webzine.Documentation/ → Documentation, StyleCop, rapports
Webzine.WebApplication/ → Application ASP.NET Core MVC
```
### B. Tests unitaires — couverture des entités
### B. Tests unitaires - couverture des entités
| Entité | Nombre de tests |
|--------|----------------|
| Artiste | 7 |
| Commentaire | 13 |
| Style | 6 |
| Titre | 29 |
| Entité | Nombre de tests |
| ----------- | --------------- |
| Artiste | 7 |
| Commentaire | 13 |
| Style | 6 |
| Titre | 29 |
### C. Packages NuGet utilisés
| Package | Usage |
|---------|-------|
| Bogus 35.6.5 | Génération de données de test réalistes |
| Faker.Net 2.0.163 | Génération de données fictives |
| NLog 6.1.1 + NLog.Web.AspNetCore | Logging |
| StyleCop.Analyzers 1.1.118 | Analyse statique du code |
| MSTest 4.0.1 | Framework de tests unitaires |
| Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation | Rechargement des vues à chaud |
| Package | Usage |
| ------------------------------------------------- | --------------------------------------- |
| Bogus 35.6.5 | Génération de données de test réalistes |
| Faker.Net 2.0.163 | Génération de données fictives |
| NLog 6.1.1 + NLog.Web.AspNetCore | Logging |
| StyleCop.Analyzers 1.1.118 | Analyse statique du code |
| MSTest 4.0.1 | Framework de tests unitaires |
| Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation | Rechargement des vues à chaud |

20
Webzine.WebApplication/Configuration/AppEnums.cs
View File

@@ -1,13 +1,33 @@
namespace Webzine.WebApplication.Configuration;
/// <summary>
/// Définit les types de seeder et de repository disponibles dans l'application.
/// </summary>
public enum SeederType
{
/// <summary>
/// Utilise des données locales pour le seeding.
/// </summary>
Local,
/// <summary>
/// Utilise des données provenant de Spotify pour le seeding.
/// </summary>
Spotify,
}
/// <summary>
/// Définit les types de repository disponibles dans l'application.
/// </summary>
public enum RepositoryType
{
/// <summary>
/// Utilise des données locales pour les opérations de repository.
/// </summary>
Local,
/// <summary>
/// Utilise une base de données pour les opérations de repository.
/// </summary>
Db,
}