Bibliothèques C# : guide de l'écosystème pour pros et débutants

Pourquoi C# n'est pas qu'un simple langage, mais tout un univers d'outils

Lorsqu'un développeur commence tout juste à plonger dans le monde de .NET, il pense souvent : « C# c'est cool, mais que puis-je faire tout de suite ? » La réponse est simple : utiliser des bibliothèques. L'écosystème C# est si riche qu'il semble parfois qu'il existe déjà une solution toute prête sur NuGet pour chaque tâche. Et c'est tant mieux, car les bibliothèques C# populaires permettent de ne pas réinventer la roue et de se concentrer sur la logique métier.

Dans cet article, nous allons explorer l'écosystème des bibliothèques .NET dont chaque développeur a réellement besoin. Nous ne nous contenterons pas de lister des noms — je montrerai des exemples de code, expliquerai où les utiliser et donnerai des conseils pratiques. C'est parti !

Journalisation : Serilog vs NLog — le choc des titans

La journalisation est la première chose à laquelle il faut penser. Sans logs, vous êtes aveugle. La bibliothèque Serilog est devenue le standard de facto dans le monde .NET. Pourquoi ? Parce qu'elle peut envoyer des logs partout : fichier, console, Elasticsearch, base de données. Et tout cela avec une configuration minimale.

Exemple : Configuration de Serilog dans ASP.NET Core

using Serilog;\n\nLog.Logger = new LoggerConfiguration()\n    .WriteTo.Console()\n    .WriteTo.File("logs/myapp-.txt", rollingInterval: RollingInterval.Day)\n    .CreateLogger();\n\nvar builder = WebApplication.CreateBuilder(args);\nbuilder.Host.UseSerilog();\n\nvar app = builder.Build();\napp.MapGet("/", () => "Hello World!");\napp.Run();

NLog est également un outil puissant, mais il nécessite plus de configuration en XML. Si vous voulez quelque chose de simple et rapide — choisissez Serilog. Si vous avez besoin d'un contrôle total — optez pour NLog. Mais pour 90% des projets, Serilog sera le choix optimal.

Entity Framework Core : un ORM à ne pas craindre

Travailler avec des bases de données est la douleur de chaque développeur. Les bibliothèques C# pour la gestion des bases de données se divisent en deux camps : les ORM lourds (Entity Framework) et les légers (Dapper). Entity Framework Core (EF Core) est un outil puissant qui génère le SQL à votre place. Il est idéal pour les modèles de domaine complexes.

Exemple : CRUD simple avec EF Core

public class User\n{\n    public int Id { get; set; }\n    public string Name { get; set; }\n}\n\npublic class AppDbContext : DbContext\n{\n    public DbSet<User> Users { get; set; }\n}\n\n// Utilisation\nusing var db = new AppDbContext();\nvar user = new User { Name = "Alexeï" };\ndb.Users.Add(user);\ndb.SaveChanges();

Mais il y a un bémol : EF Core peut être lent sur les requêtes complexes. Pour les systèmes à forte charge, il est préférable d'utiliser Dapper — un micro-ORM qui est beaucoup plus rapide, mais qui nécessite d'écrire le SQL manuellement.

Quand choisir Dapper ?

\n
• Lorsque vous avez besoin de performances maximales
\n
• Lorsque vous avez des requêtes simples (CRUD sans logique complexe)
\n
• Lorsque vous n'avez pas peur du SQL
\n

using var connection = new SqlConnection(connectionString);\nvar users = connection.Query<User>("SELECT * FROM Users WHERE IsActive = @Active", new { Active = true });

AutoMapper : un mappage sans douleur

Si vous codez en C#, vous êtes constamment confronté à la transformation d'un objet en un autre. DTO → Entité, Entité → ViewModel. Le mappage manuel est ennuyeux et source d'erreurs. AutoMapper automatise ce processus.

Exemple : Configuration d'un profil

public class UserProfile : Profile\n{\n    public UserProfile()\n    {\n        CreateMap<User, UserDto>()\n            .ForMember(dest => dest.FullName, opt => opt.MapFrom(src => $"{src.FirstName} {src.LastName}"));\n    }\n}\n\n// Utilisation\nvar config = new MapperConfiguration(cfg => cfg.AddProfile<UserProfile>());\nvar mapper = config.CreateMapper();\nvar dto = mapper.Map<UserDto>(user);

Conseil : n'abusez pas d'AutoMapper. Si le mappage est trop