Por qué deberías evitar Update() en un Repositorio Genérico en .NET MVC

A MacBook with lines of code on its screen on a busy desk

En aplicaciones desarrolladas con .NET MVC y Entity Framework Core, es común aplicar el patrón de repositorio genérico para abstraer el acceso a datos. Sin embargo, uno de los errores más frecuentes es implementar el método Update() dentro del repositorio genérico sin considerar las diferencias entre entidades.

En este artículo aprenderás por qué deberías evitar Update() en un repositorio genérico y cuándo es más apropiado delegar esta operación a repositorios específicos por entidad.


1. Cada entidad tiene reglas de actualización diferentes

Una de las principales razones para evitar Update() en un repositorio genérico es que cada entidad puede tener su propia lógica de negocio al actualizarse.

Casos comunes:

  • Algunas propiedades no deben modificarse, como FechaCreacion.
  • Otras requieren validaciones personalizadas antes de persistir los cambios.
  • Ciertos cambios pueden desencadenar acciones específicas, como enviar correos o invalidar caché.

Ejemplo en un repositorio específico:

csharpCopiarEditarpublic void Update(Producto entity)
{
    var existingProducto = _context.Productos.Find(entity.Id);
    if (existingProducto != null)
    {
        existingProducto.Nombre = entity.Nombre;
        existingProducto.Precio = entity.Precio;

        // No modificamos la fecha de creación
        _context.SaveChanges();
    }
}

👉 En un repositorio genérico, no hay forma de saber si se debe actualizar una propiedad o no.


2. No todas las entidades requieren el mismo método de actualización

En Entity Framework Core, hay distintas formas de actualizar entidades, como Entry(), Attach(), o incluso llamadas a procedimientos almacenados.

Ejemplo 1: marcar toda la entidad como modificada

csharpCopiarEditarpublic void Update(Producto entity)
{
    _context.Entry(entity).State = EntityState.Modified;
    _context.SaveChanges();
}

Ejemplo 2: modificar solo una propiedad

csharpCopiarEditarpublic void Update(Categoria entity)
{
    _context.Categorias.Attach(entity);
    _context.Entry(entity).Property(x => x.Nombre).IsModified = true;
    _context.SaveChanges();
}

📌 Si centralizas Update() en un repositorio genérico, no puedes adaptar estas estrategias a cada tipo de entidad.


3. Mejor control, mayor mantenibilidad

Otro motivo para evitar Update() en un repositorio genérico es mantener el principio de responsabilidad única y el control total sobre los efectos secundarios.

Ejemplos de lógica personalizada:

  • Usuario.Update() → puede requerir lógica para manejar el cambio de email, pero nunca debe modificar la contraseña directamente.
  • Orden.Update() → podría necesitar enviar notificaciones si cambia el estado del pedido.
  • Producto.Update() → debe ignorar ciertos campos como FechaCreacion.

➡ Si cada repositorio contiene su propia lógica de actualización, puedes modificar una sin afectar las demás. Esto mejora la mantenibilidad y previene errores globales.


¿Cuándo es aceptable usar Update() en un repositorio genérico?

Solo en casos muy controlados donde todas las entidades siguen la misma lógica de actualización. Por ejemplo:

csharpCopiarEditarpublic virtual void Update(T entity)
{
    _context.Set<T>().Update(entity);
    _context.SaveChanges();
}

⚠️ Sin embargo, esta práctica tiene varios riesgos:

  • Puede sobrescribir propiedades sensibles sin control.
  • No permite validaciones o lógica personalizada por entidad.
  • Realiza un UPDATE completo incluso si solo una propiedad cambió.

Por estas razones, se recomienda evitar Update() en un repositorio genérico, excepto en proyectos extremadamente simples o prototipos.


Conclusión

Evitar Update() en un Repositorio Genérico es una mejor práctica en aplicaciones con .NET MVC y Entity Framework Core, especialmente cuando cada entidad requiere reglas específicas al actualizarse. Al implementar Update() en repositorios específicos, ganarás:

  • Mayor control sobre la lógica de negocio
  • Mejor mantenimiento a largo plazo
  • Menor riesgo de errores silenciosos o inconsistencias

✅ La flexibilidad y robustez de tu arquitectura se verán fortalecidas al tomar esta decisión de diseño.


¿Quieres profundizar en buenas prácticas con .NET y arquitectura limpia?

Te invito a leer más artículos como:

También puedes suscribirte a mi newsletter para recibir contenido técnico exclusivo.

Te puede interesar...

Deja un comentario