149 lines
17 KiB
Markdown
149 lines
17 KiB
Markdown
# Rapport d'équipe — Projet Webzine
|
||
|
||
**Équipe 1**
|
||
**Formation :** Développement .NET niveau 1 / Dr1-P4
|
||
**Date :** Mars 2026
|
||
|
||
---
|
||
|
||
## 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 |
|
||
|
||
---
|
||
|
||
## Introduction
|
||
|
||
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.
|
||
|
||
---
|
||
|
||
**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)
|
||
-
|
||
---
|
||
|
||
## Organisation de l'équipe dév
|
||
|
||
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).
|
||
|
||
Par exemple, le travail sur l'entité `Titre` (fichier `Webzine.Entity/Titre.cs`) a impliqué la définition de toutes les contraintes de validation — longueurs min/max, champs obligatoires, libellés d'affichage — et d'ainsi valider les tests unitaires correspondants dans `Webzine.Entity.Tests/TitreTests.cs`. Ce type de tâche, apparemment simple, a demandé beaucoup de rigueur pour satisfaire les 40+ tests automatisés.
|
||
|
||
Concernant les rôles :
|
||
- Tout le monde a contribué aux entités, ce qui a favorisé une bonne compréhension commune du modèle de données.
|
||
|
||
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.
|
||
|
||
---
|
||
|
||
## Organisation de la collaboration dév / ops et travaux menés avec les ops
|
||
|
||
La collaboration avec les ops s'est concentrée principalement sur deux aspects : la configuration de l'environnement d'exécution et la mise en place des outils de qualité de code.
|
||
|
||
**Logging avec NLog**
|
||
La configuration NLog (`Webzine.WebApplication/nlog.config`) a été mise en place en collaboration : les devs exprimaient leurs besoins (logs de debug pour les contrôleurs, logs d'erreur pour la prod), Les logs sont écrits dans `/Logs/` avec rotation quotidienne, ce qui s'est avéré très utile pour déboguer les problèmes d'injection de dépendances en début de projet.
|
||
|
||
**Configuration applicative**
|
||
Le fichier `appsettings.json` contient des paramètres métier (`NombreDerniereChronique`, `NombreDeTopTitres`) qui peuvent être ajustés sans recompilation.
|
||
|
||
**Docker**
|
||
Un `.dockerignore` est référencé dans le `.csproj` de l'application web, signe que la conteneurisation était dans la feuille de route ops. La cible Docker Linux est configurée dans le projet. La collaboration s'est arrêtée à ce stade pour notre sprint, mais les bases sont posées.
|
||
|
||
---
|
||
|
||
## Problèmes techniques (dév / ops)
|
||
|
||
### Ce qui n'a pas été réalisé ou mal réalisé
|
||
|
||
**1. Interfaces de repository incomplètes**
|
||
Les interfaces `IArtisteRepository`, `ICommentaireRepository` et `IStyleRepository` (dans `Webzine.Repository.Contracts/`) sont quasiment vides — toutes leurs méthodes sont commentées. Seul `ITitreRepository` est partiellement implémenté. Cela signifie que les contrôleurs d'administration (`ArtisteController`, `CommentaireController`, `StyleController`) génèrent leurs propres données via `DataFactory` directement dans le constructeur, au lieu de passer par l'injection de dépendances. C'est une dette technique importante : le code est difficile à tester et ne respecte pas le pattern Repository que le projet était censé illustrer.
|
||
|
||
**2. Données non persistées**
|
||
Aucune persistance réelle n'est en place. `LocalEntityRepository` génère des données aléatoires à chaque démarrage, et `DbEntityRepository` est une classe vide. Cela rend l'application inutilisable pour un usage réel (une suppression de titre est perdue au prochain redémarrage). La branch `feature/database` avait été créée mais n'a pas abouti dans le temps imparti.
|
||
|
||
**3. Incohérence entre les contrôleurs d'admin et le repository**
|
||
Le `TitreController` (public) utilise correctement `ITitreRepository` injecté, mais les contrôleurs d'administration instancient `DataFactory` directement. Ce manque de cohérence rend le code plus difficile à maintenir et à faire évoluer.
|
||
|
||
**4. Formulaires d'administration sans validation côté serveur**
|
||
Les actions POST de création et modification de titres (`TitreController.Create(IFormCollection)`, `TitreController.Edit(int, IFormCollection)`) redirigent simplement vers l'index sans aucun traitement des données soumises. Le modèle de binding fort n'est pas utilisé — `IFormCollection` est passé à la place d'un ViewModel typé, ce qui empêche la validation automatique par ASP.NET Core.
|
||
|
||
### Progrès établis en 1 semaines
|
||
|
||
- 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
|
||
|
||
### 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
|
||
---
|
||
|
||
## Annexes
|
||
|
||
### A. Structure du projet
|
||
|
||
```
|
||
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.Business/ → Couche métier (non utilisée dans ce sprint)
|
||
Webzine.Business.Contracts/ → Interfaces métier
|
||
Webzine.EntitiesContext/ → Contexte EF (non utilisé)
|
||
Webzine.Documentation/ → Documentation, StyleCop, rapports
|
||
Webzine.WebApplication/ → Application ASP.NET Core MVC
|
||
```
|
||
|
||
### B. Tests unitaires — couverture des entités
|
||
|
||
| 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 | |