Bibliotecas de C#: guía del ecosistema para profesionales y principiantes

Por qué C# no es solo un lenguaje, sino un universo completo de herramientas

Cuando un desarrollador comienza a sumergirse en el mundo de .NET, a menudo piensa: «C# es genial, pero ¿qué puedo hacer ahora mismo?» La respuesta es simple: usar bibliotecas. El ecosistema de C# es tan rico que a veces parece que para cualquier tarea ya existe una solución lista en NuGet. Y eso es genial, porque las bibliotecas populares de C# permiten no reinventar la rueda, sino concentrarse en la lógica de negocio.

En este artículo analizaremos el ecosistema de bibliotecas .NET que realmente necesita todo desarrollador. No solo enumeraremos nombres: mostraré ejemplos de código, explicaré dónde aplicar cada una y daré consejos prácticos. ¡Allá vamos!

Registro: Serilog vs NLog — la batalla de los titanes

El registro es lo primero en lo que hay que pensar. Sin registros estás ciego. La biblioteca Serilog se ha convertido en el estándar de facto en el mundo .NET. ¿Por qué? Porque puede enviar registros a cualquier lugar: archivo, consola, Elasticsearch, base de datos. Y todo con una configuración mínima.

Ejemplo: Configuración de Serilog en 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 también es una herramienta potente, pero requiere más configuración en XML. Si quieres algo simple y rápido, elige Serilog. Si necesitas control total, elige NLog. Pero para el 90% de los proyectos, Serilog será la opción óptima.

Entity Framework Core: el ORM que no debes temer

Trabajar con bases de datos es el dolor de cabeza de todo desarrollador. Las bibliotecas de C# para trabajar con bases de datos se dividen en dos grupos: ORM pesados (Entity Framework) y ligeros (Dapper). Entity Framework Core (EF Core) es una herramienta potente que genera SQL por ti. Es ideal para modelos de dominio complejos.

Ejemplo: CRUD simple con 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 = "Alejandro" };\ndb.Users.Add(user);\ndb.SaveChanges();

Pero hay un detalle: EF Core puede ser lento en consultas complejas. Para sistemas de alta carga es mejor usar Dapper, un micro-ORM que funciona mucho más rápido, pero requiere escribir SQL manualmente.

¿Cuándo elegir Dapper?

\n
• Necesitas el máximo rendimiento
\n
• Tienes consultas simples (CRUD sin lógica compleja)
\n
• No le temes al SQL
\n

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

AutoMapper: mapeo sin dolor

Si escribes en C#, constantemente te encuentras con la conversión de un objeto a otro. DTO → Entity, Entity → ViewModel. El mapeo manual es aburrido y propenso a errores. AutoMapper automatiza este proceso.

Ejemplo: Configuración de un 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);

Consejo: no abuses de AutoMapper. Si el mapeo es demasiado