Bibliotecas C#: guia do ecossistema para profissionais e iniciantes

Por que C# não é apenas uma linguagem, mas todo um universo de ferramentas

Quando um desenvolvedor começa a mergulhar no mundo .NET, ele frequentemente pensa: "C# é legal, mas o que posso fazer agora?" A resposta é simples: usar bibliotecas. O ecossistema C# é tão rico que às vezes parece que para qualquer tarefa já existe uma solução pronta no NuGet. E isso é ótimo, porque as bibliotecas C# populares permitem não reinventar a roda, mas focar na lógica de negócios.

Neste artigo, vamos analisar o ecossistema de bibliotecas .NET que realmente são necessárias para todo desenvolvedor. Não vamos apenas listar nomes — mostrarei exemplos de código, explicarei onde usar cada uma e darei dicas práticas. Vamos lá!

Logging: Serilog vs NLog — a batalha dos titãs

Logging é a primeira coisa a se considerar. Sem logs, você está cego. A biblioteca Serilog tornou-se o padrão de facto no mundo .NET. Por quê? Porque ela consegue enviar logs para qualquer lugar: arquivo, console, Elasticsearch, banco de dados. E tudo isso com configuração mínima.

Exemplo: Configuração do Serilog no 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 também é uma ferramenta poderosa, mas exige mais configuração em XML. Se você quer algo simples e rápido — escolha Serilog. Se precisa de controle total — NLog. Mas para 90% dos projetos, Serilog será a escolha ideal.

Entity Framework Core: o ORM que você não precisa temer

Trabalhar com bancos de dados é a dor de todo desenvolvedor. As bibliotecas C# para trabalhar com BD se dividem em dois grupos: ORMs pesados (Entity Framework) e leves (Dapper). O Entity Framework Core (EF Core) é uma ferramenta poderosa que gera SQL para você. É ideal para modelos de domínio complexos.

Exemplo: CRUD simples com 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// Uso\nusing var db = new AppDbContext();\nvar user = new User { Name = "Alexey" };\ndb.Users.Add(user);\ndb.SaveChanges();

Mas há um detalhe: o EF Core pode ser lento em consultas complexas. Para sistemas de alta carga, é melhor usar o Dapper — um micro-ORM que é muito mais rápido, mas exige escrever SQL manualmente.

Quando escolher Dapper?

\n
• Precisa de máxima performance
\n
• Você tem consultas simples (CRUD sem lógica complexa)
\n
• Você não tem medo de SQL
\n

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

AutoMapper: mapeamento sem dor

Se você programa em C#, constantemente enfrenta a conversão de um objeto em outro. DTO → Entity, Entity → ViewModel. Mapeamento manual é entediante e propenso a erros. O AutoMapper automatiza esse processo.

Exemplo: Configuração de perfil

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// Uso\nvar config = new MapperConfiguration(cfg => cfg.AddProfile<UserProfile>());\nvar mapper = config.CreateMapper();\nvar dto = mapper.Map<UserDto>(user);

Dica: não abuse do AutoMapper. Se o mapeamento for muito