Recientemente, AutoMapper dejó de ser gratuito para ciertos escenarios, lo que generó preocupación en la comunidad .NET. Muchos desarrolladores lo usaban por costumbre para mapear entidades a DTOs y viceversa. Pero la realidad es que el mundo no se acabó: no solo se puede seguir trabajando sin AutoMapper, sino que, en muchos casos, es más conveniente crear métodos de mapeo manuales y con buenas prácticas.

¿Qué hacía AutoMapper?

AutoMapper es (o era) una librería muy popular en .NET que permitía definir reglas de mapeo entre objetos de diferentes tipos. Por ejemplo, convertir una entidad Game en un GameDto de forma automática, evitando escribir código repetitivo.

El problema es que, con el tiempo:

• Puede que la configuración se vuelva compleja.
• El rendimiento no era el mejor (porque dependía de reflexión y expresiones dinámicas).
• Los errores de mapeo muchas veces solo aparecían en runtime.
• Además se hizo comercial, lo cual no tiene nada de malo, pero siempre es bueno tener una alternativa y no sólo depender de software licenciado.

Automapper me parece una buena biblioteca, sus precios me parecen bastante razonables, es más tiene una versión Community a la que, salvo la empresa o persona que la usará facture mucho, es gratuita.

La alternativa: Haz tus propios mapeos con métodos de extensión

En lugar de depender de AutoMapper, podemos usar métodos de extensión simples, expresivos y seguros en tiempo de compilación, siempre con buenas prácticas.

Imagina que tienes esto:

Entidades

public class Customer
{
    public int Id { get; set; }
    public string FirstName { get; set; } = string.Empty;
    public string LastName { get; set; } = string.Empty;
    public int Age { get; set; }
}

Dtos

public record CustomerDto(
    int Id,
    string FullName,
    int Age
);

Servicios

public static class CustomerMapper
{
    public static CustomerDto ToDto(this Customer entity)
    {
        return new CustomerDto(
            entity.Id,
            $"{entity.FirstName} {entity.LastName}",
            entity.Age
        );
    }

    public static Customer ToEntity(this CustomerDto dto)
    {
        var names = dto.FullName.Split(' ');
        return new Customer
        {
            Id = dto.Id,
            FirstName = names[0],
            LastName = names.Length > 1 ? names[1] : string.Empty,
            Age = dto.Age
        };
    }
}

Y así mapeas con tu método, en lugar de usar los métodos de AutoMapper:

public interface ICustomerService
{
    Task<CustomerDto> GetByIdAsync(int id);
}

public class CustomerService : ICustomerService
{
    private readonly IStCustomerRepository _repository;

    public CustomerService(ICustomerRepository repository)
    {
        _repository = repository;
    }

    public async Task<CustomerDto> GetByIdAsync(int id)
    {
        var entity = await _repository.GetByIdAsync(id);
        if (entity == null)
            throw new KeyNotFoundException($"Customer with ID {id} not found");

        // aquí usas tu propio método de mapeo en lugar del método de automapper
        return entity.ToDto();
    }
}

Y así obtienes estas ventajas:

• Código simple y explícito.
• Evita dependencias externas si tu proyecto no justifica AutoMapper.
• Controlas exactamente cómo se mapean las propiedades.

¿Cuándo sí deberías considerar una librería?

Si tu proyecto es enorme y necesitas mapear cientos de objetos diferentes, quizá una librería como Mapster (gratuita y muy rápida) o Automapper pueda ayudarte a reducir algo de boilerplate. Pero en la mayoría de proyectos pequeños y medianos, hacer tus propias clases y métodos de mapeo es mejor.

Conclusión

Así que ya sabes dev, la noticia de que AutoMapper ya no es free no debería preocuparte. Al contrario, es una oportunidad para reflexionar si realmente lo necesitabas y sobretodo no ser dependiente de bibliotecas, sino más bien pulir tus skills como desarrollador de software.

En la mayoría de casos, un simple método de extensión hace el trabajo de manera más clara, más rápida y más mantenible. Así que no, el mundo no se acabó: probablemente lo simplificaste mi estimado dev! ✨

Si esta entrada te ha gustado, entonces compártela!

Créditos de imagen de portada: Basada en Foto de Luke Stackpoole en Unsplash