Structure typique d'un projet ASP.NET Core CRUD¶

Guide pratique pour reconnaître les dossiers courants, comprendre leur rôle et savoir quand une structure comme Factories devient pertinente.

Vue d'ensemble¶

Dans un CRUD ASP.NET Core classique, on retrouve généralement une structure simple composée de dossiers comme :

Controllers/
Services/
Repositories/
Data/
Models/ ou Entities/
DTOs/ ou Contracts/
Interfaces/
Migrations/

Tous les projets n'utilisent pas exactement les mêmes noms. Le choix dépend notamment du style d'architecture — MVC, architecture en couches, Clean Architecture, CQRS, etc. — et de la taille de l'application.

Les dossiers les plus courants¶

#	Dossier	Fréquence	À quoi ça sert	Exemples de fichiers
1	Controllers	Très fréquent	Gère les requêtes HTTP et expose les routes de l'API.	UsersController.cs, OrdersController.cs
2	Models	Très fréquent	Représente les données ou les objets utilisés par l'application.	User.cs, Product.cs
3	Services	Très fréquent	Contient la logique métier et orchestre les opérations de l'application.	UserService.cs, OrderService.cs
4	Data	Très fréquent	Regroupe l'accès et la configuration de la base de données.	AppDbContext.cs, DbSeeder.cs
5	Repositories	Fréquent	Encapsule les opérations d'accès aux données.	UserRepository.cs, ProductRepository.cs
6	DTOs	Fréquent	Définit les objets de transfert de données entre les différentes couches ou l'API.	UserDto.cs, CreateOrderDto.cs
7	Entities	Fréquent	Contient les entités persistées dans la base de données.	User.cs, Order.cs, Invoice.cs
8	Interfaces	Fréquent	Définit les contrats des services, repositories et autres composants.	IUserService.cs, IUserRepository.cs
9	Migrations	Fréquent	Contient l'historique des changements de schéma avec Entity Framework Core.	20260830_CreateUsers.cs
10	Contracts	Fréquent	Définit les contrats échangés, notamment les requests, responses, messages d'API et parfois les DTOs.	CreateUserRequest.cs, UserResponse.cs
11	Views	Fréquent en MVC	Contient les pages Razor rendues côté serveur.	Index.cshtml, Details.cshtml
12	ViewModels	Fréquent en MVC	Regroupe les données préparées spécialement pour une vue.	UserDetailsViewModel.cs
13	Mapping	Assez fréquent	Centralise les conversions entre les entités, DTOs et responses.	UserProfile.cs, MappingProfile.cs
14	Middleware	Assez fréquent	Intercepte les requêtes HTTP pour gérer, par exemple, les erreurs, les logs ou l'authentification.	ExceptionMiddleware.cs, LoggingMiddleware.cs
15	Extensions	Assez fréquent	Regroupe les méthodes d'extension et la configuration réutilisable.	ServiceCollectionExtensions.cs
16	Configurations	Assez fréquent	Contient la configuration des services, des entités ou des paramètres de l'application.	UserConfiguration.cs, JwtSettings.cs
17	Validators	Assez fréquent	Centralise la validation des données entrantes.	CreateUserValidator.cs
18	Exceptions	Occasionnel	Contient les exceptions personnalisées de l'application.	NotFoundException.cs, ValidationException.cs
19	Factories	Occasionnel	Centralise la création d'objets lorsque celle-ci implique des règles ou une configuration complexes.	OrderFactory.cs, UserFactory.cs
20	Helpers	Occasionnel	Regroupe des fonctions utilitaires diverses qui ne correspondent pas à une responsabilité métier précise.	DateHelper.cs, PasswordHelper.cs

Contracts et Factories : deux dossiers à ne pas confondre¶

Les deux dossiers existent dans les projets .NET, mais ils répondent à des besoins très différents.

Contracts¶

Contracts est un dossier assez fréquent. Il contient les formes de données échangées entre les composants ou avec l'extérieur de l'application :

Contracts/
├── Requests/
├── Responses/
└── DTOs/

Selon le projet, Contracts peut être utilisé à la place de DTOs, ou comme un dossier plus large qui englobe les requests, les responses, les messages d'API et les interfaces partagées.

Exemple :

public record CreateUserRequest(string Name, string Email);

public record UserResponse(int Id, string Name);

L'objectif est de définir clairement les données qui peuvent entrer ou sortir d'une couche, d'un service ou de l'API, sans exposer directement les entités de base de données.

Factories¶

Factories est moins courant dans un CRUD simple. Ce dossier devient utile quand la création d'un objet nécessite plusieurs règles métier, plusieurs variantes, des valeurs par défaut ou une configuration qui ne devrait pas être répétée partout.

Exemple de structure :

Factories/
├── UserFactory.cs
├── OrderFactory.cs
└── PaymentFactory.cs

Sans factory, on pourrait créer un objet directement à plusieurs endroits :

var order = new Order(...);

Avec une factory, la création est centralisée :

var order = orderFactory.Create(...);

La factory peut alors appliquer les règles de construction au même endroit et éviter que les services ou contrôleurs les répètent.

Est-ce nécessaire dans un CRUD normal ?¶

Dans un CRUD ASP.NET Core classique, Factories n'est généralement pas nécessaire. Les objets sont souvent créés directement dans les services, ou construits à l'aide d'un mapper :

Controllers/
Services/
Repositories/
Data/
Models/
DTOs/

On ajoute une factory lorsque la création devient suffisamment complexe pour justifier sa propre responsabilité, par exemple lorsque :

• plusieurs règles métier doivent être appliquées à la création;
• un objet possède plusieurs variantes possibles;
• des valeurs par défaut ou des étapes de configuration doivent être centralisées;
• la création nécessite plusieurs dépendances;
• le même processus de construction est répété à plusieurs endroits;
• on veut empêcher les services de connaître tous les détails de construction.

Pour un simple Create, Read, Update, Delete avec peu de règles, une factory risque surtout d'ajouter une couche inutile.

Ce qu'il faut reconnaître en premier dans un CRUD¶

Pour comprendre rapidement un projet ASP.NET Core normal, il est généralement préférable de commencer par ces dossiers :

1. Controllers — quelles routes l'API expose-t-elle ?
2. Services — où se trouve la logique métier ?
3. Repositories — comment les données sont-elles lues et sauvegardées ?
4. Data — quel contexte et quelle configuration de base de données sont utilisés ?
5. Models / Entities — quelles données sont représentées et persistées ?
6. DTOs / Contracts — quelles données entrent et sortent de l'API ?
7. Interfaces — quelles abstractions sont utilisées pour relier les couches ?
8. Migrations — comment le schéma de la base de données a-t-il évolué ?

Les dossiers comme Factories, Middleware, Validators et Mapping apparaissent davantage lorsque le projet grossit ou adopte une architecture plus structurée.

Résumé rapide¶

Dossier	À retenir
Contracts	Fréquent; définit les données échangées, souvent avec Requests/, Responses/ et DTOs/.
Factories	Occasionnel; centralise la création d'objets complexes.
CRUD simple	Une factory n'est généralement pas nécessaire.
Projet plus complexe	Une factory peut réduire la duplication et isoler les règles de construction.