Ir al contenido principal

Data Annotations .NET

Validaciones en .NET con Data Annotations 

En el desarrollo de aplicaciones con .NET, una de las formas más eficientes de validar y describir las propiedades de un modelo es mediante Data Annotations. En este artículo exploraremos qué son, cómo utilizarlas y en qué proyectos son aplicables.

¿Qué son las Data Annotations?

Las Data Annotations son atributos que se agregan a las propiedades de un modelo para validar datos, proporcionar metadatos o describir su comportamiento. Estas anotaciones permiten que .NET valide automáticamente la entrada de datos sin necesidad de escribir código adicional.

Por ejemplo, si en el modelo existe un campo obligatorio o un formato específico, con solo agregar una anotación se puede verificar su validez automáticamente.

Biblioteca Necesaria

    using System.ComponentModel.DataAnnotations;

Esta biblioteca incluye las anotaciones más comunes como Required, StringLength, RegularExpression, Range y otras que veremos más adelante. Si se trabaja con ASP.NET MVC o Entity Framework, esta biblioteca ya viene incluida por defecto en el proyecto.

Ejemplo Práctico

Veamos un ejemplo sencillo. Se está desarrollando un sistema de gestión de Artículos y  se necesita validar que el código del artículo sea obligatorio, tenga un formato específico y que su nombre tenga una longitud máxima entonces se podría manejar de la siguiente manera:

 using System.ComponentModel.DataAnnotations;

namespace Entidades
{
    public class Articulo
    {
        // Propiedades
        [Required(ErrorMessage = "El código del artículo es obligatorio.")]
        [RegularExpression(@"^[a-zA-Z0-9]{10}$", ErrorMessage = "Código inválido.")]
        [Display(Name = "Código")]
        public string CodArt { get; set; }

        // Constructor
        public Articulo() { }
    }
}

Explicación:
  • [Required]: Indica que el campo es obligatorio y no puede quedar vacío.
  • [RegularExpression]: Valida un formato específico usando expresiones regulares. (Expresiones regulares en .NET)
  • [Display]: Cambia el nombre visible en la interfaz de usuario.

Además de las comentadas, existen otras anotaciones comunes en .NET, especialmente dentro del espacio de nombres System.ComponentModel.DataAnnotations. 

Algunos ejemplos podrían ser:

1. [StringLength]: Especifica la longitud máxima y mínima permitida de una cadena.
 
[StringLength(50, MinimumLength = 5, ErrorMessage = "El nombre debe tener entre 5 y 50 caracteres.")]
2. [Range]: Restringe el valor de un campo a un rango numérico o de fechas.
 
[Range(18, 99, ErrorMessage = "La edad debe estar entre 18 y 99 años.")]
3. [MaxLength] | [MinLength]: Es similar a StringLength, especifica la longitud máxima o mínima de una cadena o colección.
[MaxLength(100, ErrorMessage = "El nombre no puede tener más de 100 caracteres.")]
[MinLength(3, ErrorMessage = "El nombre debe tener al menos 3 caracteres.")]
4. [EmailAddress]: Valida que el valor sea un formato de correo electrónico válido.
[EmailAddress(ErrorMessage = "Debe ser una dirección de correo válida.")]
5. [Phone]: Valida que el valor sea un número de teléfono válido.
 
[Phone(ErrorMessage = "Número de teléfono inválido.")]
6. [Url]: Valida que el valor sea una URL válida.
[Url(ErrorMessage = "Debe ser una URL válida.")]
7. [Key]: Define una clave primaria en un modelo (útil en Entity Framework).
 
[Key]
public int Id { get; set; }
Entre otras.

¿En qué tipo de proyectos puedo usar Data Annotations?

Las Data Annotations son extremadamente versátiles y es posible utilizarlas en varios tipos de proyectos:

  • ASP.NET MVC: Ideal para validar datos en formularios web y mostrar mensajes de error al usuario.
  • ASP.NET Core: Permite validar modelos en APIs REST o aplicaciones web modernas.
  • Entity Framework (EF y EF Core): Las anotaciones ayudan a definir restricciones y metadatos en la base de datos.
  • Aplicaciones de escritorio: Puedes usar las anotaciones con WPF o WinForms junto con validaciones manuales.
Dicho esto..


Debemos tener presente que las validaciones mediante Data Annotations no se ejecutan automáticamente al crear un objeto manualmente con un constructor en .NET. Estas validaciones forman parte del modelo de validación de .NET y otras herramientas como Entity Framework y se aplican explícitamente en casos como los siguientes (a nivel de ejemplo):

.NET FW MVC o .NET Core: Cuando se envían datos desde una vista (formulario) hacia un controlador, el framework de MVC valida automáticamente el modelo utilizando las Data Annotations. 

Esto se activa mediante ModelState.IsValid en tu controlador. ModelState.IsValid verifica las propiedades del modelo decoradas con Data Annotations y muestra mensajes de error cuando la validación falla.

Validaciones Manuales con Validator.TryValidateObject: Si se crea un objeto manualmente (por ejemplo, con un constructor), las validaciones no se ejecutarán automáticamente. 

Para validar manualmente las Data Annotations, se debe utilizar la clase Validator del namespace System.ComponentModel.DataAnnotations.

Entity Framework: En Entity Framework y EF Core, las validaciones se aplican automáticamente cuando guardas los cambios en la base de datos mediante SaveChanges(). 

Entity Framework valida los atributos decorados con Data Annotations antes de persistir los datos en la base de datos.
Etiquetas:
Ubicación: Uruguay

Otros artículos

Principio de Responsabilidad Única (SRP) – SOLID explicado con ejemplos

Introducción a S.O.L.I.D En esta entrada, intentaremos abordar un nuevo ciclo de conceptos que tienen que ver sobre los principios SOLID , que son fundamentales en la programación orientada a objetos o POO . Estos principios fueron formulados, en principio, por Robert C. Martin , también conocido como " Uncle Bob ", con el objetivo de mejorar la mantenibilidad y escalabilidad del código de software. SOLID es un acrónimo que representa cinco principios de diseño: Single Responsibility Principle (SRP) – Principio de Responsabilidad Única Open/Closed Principle (OCP) – Principio de Abierto/Cerrado Liskov Substitution Principle (LSP ) – Principio de Sustitución de Liskov Interface Segregation Principle (ISP) – Principio de Segregación de Interfaces Dependency Inversion Principle (DIP) – Principio de Inversión de Dependencias Estos principios nos ayudan a crear software más ...
Más entradas »

Principio de Sustitución de Liskov (LSP) – SOLID explicado con ejemplos

¿Qué es el Principio de Sustitución de Liskov? Imaginá que tenés un control remoto universal diseñado para funcionar con cualquier televisor. Si un nuevo modelo de TV no responde a los mismos comandos, el control deja de ser útil. El Principio de Sustitución de Liskov es como una garantía de que cualquier 'televisor' (o clase derivada) va a funcionar correctamente con el 'control remoto' (o clase base). El Principio de Sustitución de Liskov ( LSP ) es el tercer principio de SOLID , representado por la letra L y establece que: Los objetos de una clase derivada deben poder sustituir a los objetos de su clase base sin afectar el comportamiento correcto del programa. En otras palabras, si una clase hija hereda de una clase padre, cualquier instancia de la clase hija debería poder usarse en lugar de una instancia de la clase padre sin alterar la funcionalidad esperada. ¿Quién es Bárbara Liskov? Bárbara Liskov es una destacada científi...
Más entradas »

Open/Closed Principle (OCP) – SOLID explicado con ejemplos

Continuando con el repaso de los principios de S.O.L.I.D. que inició en el hilo anterior - si no lo viste hacé click acá  Principio de Responsabilidad Única (SRP) - vamos a ver el segundo en orden de aparición: Principio de Abierto/Cerrado (OCP por sus siglas en inglés). Definición Formal El principio OCP (Open/Closed Principle) establece que el código de una clase o un módulo debe estar abierto para la extensión, pero cerrado para la modificación. Esto significa que no se deben realizar cambios en el código existente cuando se requiere alterar alguna funcionalidad. En lugar de modificar el código existente, se debe crear una nueva implementación que extienda la funcionalidad. La única excepción a esto son los arreglos de bugs, donde está permitido modificar el código existente. Si se desea introducir una nueva funcionalidad, como la ordenación en un método existente, en lugar de modificar el código, se crearía una nueva implementación q...
Más entradas »

Paginando listados - CRUD MVC .NET Framework

En el desarrollo de aplicaciones web, es común lidiar con grandes volúmenes de datos. La paginación es una técnica útil que permite dividir los datos en partes más pequeñas y manejables. En esta entrada del blog, exploraremos cómo implementar la paginación en una vista que muestra un listado de videojuegos utilizando X.PagedList en una aplicación ASP.NET .Framework MVC5 con Entity Framework. X.PagedList es una biblioteca en .NET que se utiliza para la paginación de datos en aplicaciones web, especialmente en ASP.NET MVC. Su propósito principal es ' dividir ' grandes conjuntos de datos en páginas más pequeñas, facilitando la navegación y el rendimiento de las aplicaciones. Existen dos versiones populares de esta biblioteca actualmente: PagedList.Mvc (Más antigua, ya no mantenida oficialmente) X.PagedList (Versión más moderna y recomendada) Funciona tanto para .NET Framework como para .NET Core y .NET 5+ ....
Más entradas »

Principio de Segregación de Interfaces (ISP) – SOLID explicado con ejemplos

El Principio de Segregación de Interfaces es otro de los principios SOLID y establece que: Una clase no debería verse obligada a depender de métodos que no utiliza .  En otras palabras, en lugar de crear una interfaz grande con muchos métodos, es mejor dividirla (segregar) en interfaces más pequeñas y específicas. Pero.. ¿Por qué? Obliga a implementar métodos innecesarios Si una clase solo necesita una "parte" de la funcionalidad de una interfaz, pero esta interfaz es muy grande, se va a ver obligada a implementar métodos que no usa. Esto es casi que inevitable si no buscamos la manera de separar mejor las responsabilidades. Imaginemos una interfaz IVehiculo que tiene los siguientes métodos: public interface IVehiculo { void Conducir () ; void Volar () ; void Navegar () ; } Si una clase Auto implementa esta interfaz, se ve obligado a definir métodos como Volar() o Navegar() , aunque un auto no vuela ni navega. public c...
Más entradas »

El patrón Singleton en C#

Patrones de Diseño Los patrones de diseño, son soluciones reutilizables para problemas comunes que enfrentan los desarrolladores durante el diseño de sistemas de software. Ayudan a estructurar el código de manera eficiente y escalable, proporcionando guías para resolver problemas específicos dentro de cierto contexto. Entre los patrones más conocidos en .NET se encuentran patrones como  Fachada , que organiza componentes o el Singleton , que se aplica directamente a una clase para el control de instancias, entre otros. Estos patrones, generalmente se clasifican en tres tipos principales: Patrones creacionales Patrones Estructurales Patrones de Comportamiento Singleton entra en la categoría de patrón creacional y estos se enfocan en cómo se crean los objetos de un componente. ¿Qué es el Patrón Singleton? El patrón Singleton asegura que una clase tenga una sola instancia accesible globalmente y proporciona un punto de acceso centralizado a dicha insta...
Más entradas »