Cuando se trabaja en un proyecto web por lo general se tiene bien definida una capa que se encarga de las entidades de dominio, en esa capa se definen clases que corresponden con la información de una o varias tablas de tu base de datos (ya sea que tu definas cada clase a partir de una base de datos existente o que utilices Entity Framework).
Lo cierto es que cada entidad de dominio tiene validaciones que deben cumplirse, es ahí donde se utiliza DataAnnotations para validar la información que se ingresa vía entidades de dominio a nuestra base de datos.
DataAnnotations ayuda a definir las reglas para las clases del modelo o propiedades para la validación de datos y la visualización de los mensajes adecuados a los usuarios finales, se encuentra en el espacio de nombres System.ComponentModel.DataAnnotations.
Data Annotation Validator Attributes
[DataType]: especifica el tipo de dato que se espera recibir. [DisplayName]: especifica el titulo que se presentara en la vista. [DisplayFormat]: specify the display format for a property like different format for Date property. [Required]: especifica que una propiedad debe especificarla obligatoriamente. [ReqularExpression]: especifica la validación utilizando una expresión regular. [Range]: especifica el rango de valores validos. [StringLength]: especifica la longitud máxima y mínima de un string. [MaxLength]: especifica la longitud máxima de una propiedad. [Bind]: especifica aquellas propiedades a las que ASP.NET MVC va llevar información desde la vista hasta el modelo, es decir, la propiedad aparecerá en la vista y estará disponible para que el usuario introduzca un valor pero ese valor que se introduzca en el campo de texto ID(por ejemplo) no se va enlazar con la entidad de negocio, ni siquiera es recibida por el controlador[HttpPost], es como engañar al usuario pero más bien se utiliza como medida de seguridad. [ScaffoldColumn]: esconde una propiedad del helper HTML como EditorForModel y DisplayForModel, este atributo acepta un parámetro booleano, recuerda que como esta propiedad no está disponible al usuario a través de una vista, al aceptar los datos desde la vista en el controlador[HttpPost] quizás deberás especificar un valor para la propiedad.
Las propiedades candidatas para ScaffoldColumn son claves primarias y claves foráneas, también aquellas que requieran cálculos a partir de la existencia de otros valores.
Recordar que ambos atributos funcionan al utilizar el helper @Html.EditorForModel(), si tú haces tus propios formularios el atributo ScaffoldColumn o el atributo Bind no tienen sentido, a lo mucho te servirá de orientación sobre las propiedades de tu modelo, pero se supone que eso ya está debidamente documentado…o debería.
Como recomendación, es mejor crear una ViewModel que responda con los campos que quieren mostrarse al usuario para no abusar y detallar los atributos DataAnnotations que en verdad nos sean útiles, a mas no haber alternativa puede utilizarse una Buddy Class.
Aquí va un ejemplo para una entidad de dominio Employee:
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using System.Web.Mvc;
namespace Employee.Models
{
[Bind(Exclude = "EmpId")]
public class Employee
{
[ScaffoldColumn(false)]
public int EmpId { get; set; }
[DisplayName("Employee Name")]
[DataType(DataType.Text)]
[Required(ErrorMessage = "Employee Name is required")]
[StringLength(100,MinimumLength=3)]
[CannotContainNumbers]
public String EmpName { get; set; }
[Required(ErrorMessage = "Employee Address is required")]
[DataType(DataType.Text)]
[StringLength(300)]
public string Address { get; set; }
[Required(ErrorMessage = "Salary is required")]
[Range(3000, 10000000,ErrorMessage = "Salary must be between 3000 and 10000000")]
public int Salary{ get; set; }
[Required(ErrorMessage = "Please enter your email address")]
[DataType(DataType.EmailAddress)]
[Display(Name = "Email address")]
[MaxLength(50)]
[RegularExpression(@"[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,4}", ErrorMessage = "Please enter correct email")]
public string Email { get; set; }
[DataType(DataType.PhoneNumber)]
[RegularExpression("^[0-9]{8}$")]
[StringLength(32)]
public string Phone { get; set; }
[DataType(DataType.Date)]
public DateTime Birthday { get; set; }
[DataType(DataType.MultilineText)]
[StringLength(255)]
public string Remarks { get; set; }
}}
Es así de fácil, el único problema(o problemon dependiendo de tu nivel) es que las validaciones se hacen en el lado del servidor, esto significa que, al momento de enviar un formulario que contiene errores de validación, el control pasa al servidor sólo para regresar con mensajes de error. Para evitar este ida y vuelta puede agregar capacidades de validaciones del lado del cliente a la vista entonces…
Adición de capacidades de validación de cliente.
Cuando ya estén definidas las validaciones para el modelo utilizando data annotations, estas van a ser utilizadas automáticamente por los Html Helpers en las vistas, pero antes debemos asegurarnos de agregar estas etiquetas
Recuerda que se hacen referencia a Bundles pues facilita la importación de librerías, también se utiliza el helper Url.Content () para obtener URLs de tres archivos de script, a saber. jquery-X.X.X.js, jquery.validate.js y jquery.validate.unobtrusive.js.
Estos archivos son necesarios para llevar a cabo la validación del lado del cliente. Ahora, web.config abierto y asegurar que existen las siguientes especificaciones en la sección :
Y revisar que el archivo ~\App_Start\BundleConfig.cs incluya lo siguiente
Si usamos los atributos estándar (no creamos atributos propios) ya tenemos la validación en cliente automática. Es decir al mismo tiempo que el usuario vaya tecleando los valores o cambie el foco ya ser irán mostrando los distintos errores que haya y si hay errores no podrá enviar el formulario.
Por supuesto la validación en cliente no tiene nada que ver con la seguridad, es un tema de usabilidad (darle feedback al usuario de forma más rápida) así que el uso de validación en cliente no inhibe de realizarla en servidor. ASP.NET MVC la realiza siempre en servidor (y nosotros por nuestra parte debemos comprobar siempre el valor de la propiedad IsValid del ModelState).
Si por alguna razón se desea desactivar la validación en cliente en alguna vista, basta con llamar al método Html.EnableClientValidation con el parámetro a false:
@{ Html.EnableClientValidation(false); }
@using (Html.BeginForm())
{
// Codigo del form
}
Este sería un ejemplo de la vista utilizando la entidad de dominio Employee debidamente validada, para evitar confusiones aclaro que cree la vista fuertemente tipada
A continuación expongo los atributos de validación que DataAnnotations nos entrega y que muestran cierta complejidad, recuerda que también puedes utilizar expresiones regulares o bien crear tus validaciones personalizadas.
Validacion de password
[Required]
[DataType(DataType.Password)]
[DisplayName("Password")]
public string Password { get; set; }
[Required]
[DataType(DataType.Password)]
[DisplayName("Confirm Password")]
[SameAs("Password", ErrorMessage = "It should be similar to Password")]
public string ConfirmPassword { get; set; }
Validacion de precios
[Required(ErrorMessage = "Price is required")]
[Range(0.01, 999999999, ErrorMessage = "Price must be greater than 0.00")]
[DisplayName("Price ($)")]
public decimal Price { get; set; }
[Integer(ErrorMessage="This is needs to be integer")]
public int CustomerId { get; set; }
[Integer]
[Min(1, ErrorMessage="Unless you are benjamin button you are lying.")]
[Required]
public int Age { get; set; }
Validacion de fechas.
Para obtener el formato dd/mm/yyyy = 24/12/2015 se puede utilizar el atributo
para obtener el formato fecha y hora se puede utilizar el atributo
[DataType(DataType.DateTime)]
public DateTime? StartDate { get; set; }
Validación de extensión de archivos
[FileExtensions("png|jpg|jpeg|gif")]
public string ProfilePictureLocation { get; set; }
Validaciones utilizando expresiones regulares.
La primera opción es crear el conjunto de validaciones que utilizan expresiones regulares en un archivo independiente e importar este archivo desde la clase que defina la entidad de negocio, para este ejemplo se validara la dirección de correo electrónico
namespace MyProject.Attributes.Validation{
using System.ComponentModel.DataAnnotations;
public class EmailAttribute : RegularExpressionAttribute{
public EmailAttribute()
: base(@"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}")
{
this.ErrorMessage = "Please provide a valid email address";
}
}
}
Y en la clase que define la entidad de negocio
using MyProject.Attributes.Validation;
public class MyModel
{
[Required]
[Email]
public string EmailAddress { get; set; }
}
La segunda opción es definir la expresión regular en la misma propiedad dentro de la definición de entidad de negocio
[RegularExpression(@"a-z, A-Z", ErrorMessage = "Solo letras")]
public string LastName { get; set; }
[RegularExpression(@"^[0-9]{0,15}$", ErrorMessage = "Definir solo numeros")]
public string PhoneNumber { get; set; }
[RegularExpression(@"^\w+@[a-zA-Z_]+?\.[a-zA-Z]{2,3}$", ErrorMessage = "formato invalido")]
public string eMail { get; set; }
Creando Validaciones Personalizadas.
como primera recomendacion lo mejor es crear un folder donde se guardaran las validaciones personalizadas, estas deben hererdar la clase ValidationAttribute y se sobrescribe el método ValidationResult IsValid
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.ComponentModel.DataAnnotations;
using System.Text.RegularExpressions;
namespace Custom_DataAnnotation_Attribute.Models {
public class CustomEmailValidator : ValidationAttribute {
protected override ValidationResult IsValid(object value, ValidationContext validationContext)
{
if (value != null){
string email = value.ToString();
if (Regex.IsMatch(email, @"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}", RegexOptions.IgnoreCase))
{
return ValidationResult.Success;
}
else
{
return new ValidationResult("Please Enter a Valid Email.");
}
}
else
{
return new ValidationResult("" + validationContext.DisplayName + " is required");
}
}
Y desde la entidad de negocio se utilizaría así
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.ComponentModel.DataAnnotations;
namespace Custom_DataAnnotation_Attribute.Models
{
public class EmployeeModel
{
public string Name { get; set; }
[CustomEmailValidator]
public string Email { get; set; }
public string Password { get; set; }
public string Mobile { get; set; }
}
}
También se puede crear una validación personalizada en la cual la clase utilice un constructor, así
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.ComponentModel.DataAnnotations;
namespace CustomValidation.CustomValidator
{
public class CustomPasswordValidator:ValidationAttribute
{
private readonly int minLen;
private readonly int maxLen;
//The constructor accepts two parameters. These parameters have to be supplied while applying this attribute.
//We are also passing a default message to base class. This is default message.
public CustomPasswordValidator(int minLength, int maxLength)
: base("{0} length should be between " + minLength + " and " + maxLength + "")
{
minLen = minLength;
maxLen = maxLength;
}
//We have override the IsValid method which accepts value and ValidationContext object.
//value is the input provided by user from Form. The value which is posted from form.
//Validation context object has details about the property on which this attribute is used.
protected override ValidationResult IsValid(object value, ValidationContext validationContext)
{
//Validating user input.
//The value is null, if the user leaves age field balnk on form.
//We are returing error message in the else part of this if.
//This check works like Required attribute.
if (value != null) {
//Converting the value to integer from object type.
string userValue = value.ToString();
//Comparing the length of password entered with the minimum limit.
if (userValue.Length < minLen){
//If the length of password is less than the applied length, validation message is thrown.
return new ValidationResult("Password cannot be less than 6 letters.");
}
//Comparing the length of password entered with the maximum limit.
else if (userValue.Length > maxLen){
//If the length of password is greater than the applied length, validation message is thrown.
return new ValidationResult("Password cannot be greater than 12 letters");
}
else
{
//If the supplied password passes all the validations success result is returned.
return ValidationResult.Success;
}
}
else
{
//If the user does not provide his password. The mandatory error message is shown.
return new ValidationResult("Password is manadatory Field.");
} } } }
Y se aplica de la siguiente manera:
[DataType(DataType.Password)]
[CustomPasswordValidator(6,12)]
public string Password { get; set; }
un ultimo ejemplo para validar string con longitud definida
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.ComponentModel.DataAnnotations;
namespace CustomValidation.CustomNameValidator
{
//Inherited the base class ValidationAttribute to create our own Custom Attribute.
public class CustomNameValidator : ValidationAttribute
{
private readonly int maxWords;
//The constructor accepts single parameter i.e. maximum limit to check the count of words.
//This can be used to validate FirstName to have specified number of words.
//We are also passing a default message to base class. This is default message.
public CustomNameValidator(int maximumLimit)
: base("{0} should be less than " + maximumLimit + " letters.")
{
//We are setting a private variable MaxWords with maximum limit which is specified while defining attribute.
maxWords = maximumLimit;
}
//We have override the IsValid method which accepts value and ValidationContext object.
//value is the input provided by user from Form. The value which is posted from form.
//Validation context object has details about the property on which this attribute is used.
protected override ValidationResult IsValid(object value, ValidationContext validationContext)
{
//Checking if the value is null.
if (value != null)
{
//casting the object value to string.
var valueAsString = value.ToString();
//comparing the input value length and the length specified while defining attributes.
if (valueAsString.Length < maxWords)
{
//If the input length is within the maximum length allowed then attribute will return Success.
return ValidationResult.Success;
}
else
{
//If the input length is not withing the maximum length, then error message is returned.
//As we have passed the default message above. We have passed a placeholder with it.
//The display name is passed as parameter. And error message is displayed.
var errorMessage = FormatErrorMessage(validationContext.DisplayName);
return new ValidationResult(errorMessage);
}
}
else
{
//If value is null, we are returning error message. This validation works like Required attribute.
//In below line we are passing display name and message as well.
return new ValidationResult("" + validationContext.DisplayName + " is manadatory field");
}
}
}
}
Aplicando:
[CustomNameValidator.CustomNameValidator(40)]
public string LastName { get; set; }
Donde especificamos las DataAnnotations?
Hay escenarios en los que no tenemos acceso a la clase en la que deseamos introducir las anotaciones. Un ejemplo claro lo encontramos cuando nos interesa especificar las restricciones en una clase generada por un proceso automático, como el diseñador de EDM de Entity framework; cualquier cambio realizado sobre el código generado será sobrescrito sin piedad al modificar el modelo, supongamos tengo esta tabla que cuya entidad fue creada vía Entity Framework
CREATE TABLE [dbo].[Friend](
[UserId] [int] IDENTITY(1,1) NOT NULL,
[FirstName] [nvarchar](100) NOT NULL,
[LastName] [nvarchar](100) NOT NULL,
[BirthDate] [date] NOT NULL,
CONSTRAINT [PK_Friend] PRIMARY KEY CLUSTERED
(
[UserId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
Esta tabla solo tendrá una lista de personas, luego he añadido mi ADO.NET Entity Data Set, en mi carpeta Modelo, que crea un objeto para esta tabla. Como he señalado, cualquier cambio tal como una validación sobre esta clase se van a reemplazar cada vez que se vuelve a generar. Este es un problema cuando se quiere agregar algunos atributos de la clase.
En estos casos, es una práctica frecuente definir los metadatos en clases “buddy”, que son copias exactas de la entidad a anotar, pero que serán utilizadas únicamente como contenedores de anotaciones.
Las clases buddy se vinculan con la entidad original utilizando el atributo MetadataType de la siguiente forma:
using System;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel;
namespace MVCBuddyClass.Models{
[MetadataType(typeof(FriendMeta))]
public partial class Friend
{ }
public class FriendMeta{
[DisplayName("First Name")]
public string FirstName { get; set; }
[DisplayName("Last Name")]
public string LastName { get; set; }
[DisplayName("Date of Birth")]
public DateTime BrithDate { get; set; }
}
}
Observa que para poder utilizar esta técnica es necesario que la entidad a la que queremos añadir anotaciones sea creada como parcial. En caso contrario no podríamos indicarle con MetadataType dónde se encuentran definidos sus atributos de validación.
El código anterior funciona, pero hay programadores que piensan que la manera correcta es utilizar una internal sealed class, necesaria para emparentar los atributos.
[MetadataType(typeof(CategoryMetaData))]
public partial class Category{
internal sealed class CategoryMetaData{
private CategoryMetaData()
{ }
[Required]
public string Name { get; set; }
[StringLength(20)]
public string Code { get; set; }
[Display(Name="Category Description")]
public string Description { get; set; }
}
}
ViewModel Class
La mejor opción es utilizar View Model class pues permite especificar las propiedades que queremos que aparezcan en la vista, sobre estas propiedades se pueden definir validaciones utilizando DataAnnotations
[ValidateAntiForgeryToken]
Una aplicación web es vulnerable a los ataques CSRF (Cross Site Request Forgery), también conocidos como XSRF o Session Riding, cuando no establece ningún mecanismo para verificar que una petición de un usuario confiable ha sido efectivamente realizada de forma intencionada por ese usuario, más sencillo: el ataque CSRF aprovecha que el usuario está autenticado en la aplicación vulnerable para hacer una petición en su nombre.
El filtro [ValidateAntiForgeryToken] nos ayudará a defendernos contra la falsificación de entidades entre sitios. Podemos añadir en nuestro formulario el helper AntiForgeryToken, que generará un token dentro de un campo oculto, por otro lado decoramos nuestro método de acción para el post del formulario con el filtro ValidateAntiForgeryToken.
Cuando el usuario rellene el formulario y envie la petición (submit), ASP.NET MVC comprobará que el token enviado es correcto. Esto lo hara comporando una cookie que habrá creado con el token contra el campo de formulario.
Decoramos la acción del post del formulario con el filtro
[ValidateAntiForgeryToken]
public ActionResult SubmitPost(ViewModel vm)
{
...
}
[OutputCache]
Permite guardar información en cache a fin de optimizar el rendimiento de la aplicación, el uso mas básico de este atributo se muestra
[OutputCache(Duration=60,VaryByParam="none")]
public ActionResult Index()
{
var employees = db.Employees;
return View(employees.ToList());
}
Sin embargo, algunas veces será necesario deshabilitar la cache para determinadas acciones (generalmente cuando se hace una llamada Ajax ciertos navegadores por defecto almacenan el resultado en cache, pudiendo producir un efecto no esperado en nuestras aplicaciones). Utilizando el mismo atributo, podremos deshabilitar la cache de las siguientes formas:
Por defecto, al usar el atributo [OutputCache], el contenido se cachea en 3 ubicaciones:
el servidor web
en los servidores proxy intermedios
en el navegador del cliente
Podemos de todas formas controlar donde exactamente queremos que se cachee el contenido modificando la propiedad Location del atributo [OutputCache]
La propiedad Location puede tener los siguientes valores:
Any
Client
Downstream
Server
None
ServerAndClient
Nunca guardes información del usuario en el servidor !!!
Por defecto, el valor asignado a Location es Any. Sin embargo hay situaciones donde nos puede interesar cachear sólamente en el navegador o sólamente en el cliente. Por ejemplo, si cacheamos información personalizada por cada usuario, no queremos almacenar esa información en el servidor, pero si queremos mostrar información de una lista de productos desde la base de datos entonces puede servirnos el cachear esta información en el servidor.
Como el cache es compartido por todos los usuarios de nuestra aplicación, no debemos cachear nunca contenido personalizado en el servidor. En todo caso, podemos enviar al navegador la directiva para que lo cachee en el cliente, y no se realice la petición al servidor. Por ejemplo:
Atributo CacheProfile
En el web.config se debe agregar el perfil de cache con sus respectivos valores
Y así se utilizaría
[OutputCache(CacheProfile="Long")]
public ActionResult Index()
{
var employees = db.Employees;
return View(employees.ToList());
}
El atributo [OutputCache] viene a ser útil en el área de Login
Permite indicar cuándo la información recibida debe ser validada para evitar la entrada de contenido potencialmente peligroso, como etiquetas de marcado o scripts, de forma muy similar a la directiva ValidateRequest utilizada en páginas Webforms.
Por defecto, ASP.NET MVC framework validará las entradas a no ser que indiquemos lo contrario:
[ValidateInput(false)]
public ActionResult Update(Friend friend)
{
// ...
}
Este tipo de validación puede ayudar a evitar ataques de inyección de scripts en nuestros sitios web.
Hasta ASP.NET MVC 2 esta era la única vía para evitar la recepción de contenido potencialmente peligroso, y realmente era algo limitada, puesto que la validación se realizaba a nivel de acción. Si en un formulario existían unos campos que debían ser validados y otros que no, era necesario desactivarla a nivel de la acción completa.
En MVC 3 se introdujo otra posibilidad, bastante más acertada, que permite indicar exactamente qué propiedades son las que queremos que no sean validadas. Así, por defecto, serán validadas todas menos las que incorporen el atributo [AllowHtml] de la siguiente forma:
public class News
{
[Required]
public string Title { get; set; }
[Required, AllowHtml]
public string Text { get; set; }
public DateTine Date { get; set; }
}
[HandleError]
El atributo [HandleError] permite especificar el tratamiento que se dará en caso de producirse excepciones en las acciones a las que se aplica, normalmente enviar al usuario una vista describiendo el problema.
Por defecto si se produce un error en la aplicación, ASP.NET y al utilizar el atributo [HandleError] sin parámetros sobre una acción provocará que todas las excepciones de tipo System.Exception (o en otras palabras, todas) sean tratadas de la misma forma, esto es, redirigiendo a la vista Error situada en Views/shared de nuestro proyecto. Podemos cambiar este coportamiento predeterminado de este filtro ajustando varias de sus propiedades.
ExceptionType: Para indicar los tipos de excepción que controlará el filtro.
View: Nombre de vista que utilizará el filtro para mostrar el error.
Master: Especifica el nombre de la vista maestra que se va a utilizar, si es que vamos a utilizar alguna vista maestra.
Order: Orden en el que se aplican los filtros. Vamos a hablar sobre esto más adelante en este artículo.
Para habilitar el uso de los errores personalizados hay que añadir el elemento customErrors a system.web del archivo web.config.
;
;
[HandleError]
public ActionResult Test()
{
throw new Exception(); // Shows the view "Error"
}
También es posible concretar el tipo de excepción que se desea capturar, ofreciendo la posibilidad de mostrar al usuario vistas distintas en cada caso.
Por ejemplo, en el siguiente código se indica al framework que si en el método Divide() se produce un error de división por cero, se mostrará al usuario la vista "MathError", mientras que si la excepción lanzada es de tipo ArgumentException se retornará una vista distinta:
[HandleError(ExceptionType=typeof(DivisionByZeroException),
View="MathError")]
[HandleError(ExceptionType=typeof(ArgumentException),
View="ArgumentError")]
public ActionResult Divide(int a, int b)
{
// ...
}
HandleError también puede ser establecido a nivel de controlador, aplicándose a todas las acciones de éste.
El manejador de errores que se empleará en una acción será el primero que corresponda al tipo de excepción producida, teniendo en cuenta tanto los filtros HandleError especificados a nivel de clase controlador como a nivel de método, y siempre siguiendo un orden, que es posible modificar utilizando la propiedad Order:
[HandleError(View="GenericError", Order=10)]
public class CalculatorController: Controller
{
[HandleError(ExceptionType=typeof(DivisionByZeroException), Order=1,
View="MathError")]
public ActionResult Divide(int a, int b)
{
// ...
}
}
En este ejemplo, una excepción de división por cero será gestionada como se indica a nivel de acción, puesto que estamos forzando que sea la primera en procesarse. Si no se indica el orden, en este caso se enviaría al usuario el error genérico, puesto que éste es el primero en definirse a nivel de clase.
El orden de proceso de los filtros no es determinista cuando no se define un orden específico, es decir, no podemos saber cuál de ellos se va a ejecutar primero. Por tanto, en escenarios en los que las acciones sean afectadas por más de un atributo de este tipo, lo más recomendable es establecer el orden.
Crear atributos personalizados
Un filtro no es más que un objeto que tiene la posibilidad de ejecutar código durante cuatro posibles instantes del ciclo de vida de una petición:
Antes de ejecutar la acción
Después de ejecutar la acción
Antes de generar el resultado
Después de generar el resultado
Para crear nuestro filtro personalizado deberemos dirigirnos a la carpeta Filters de nuestra aplicación, hacer click derecho y seleccionar Add > Class…
A continuación asignaremos un nombre a la clase. Como podemos ver en la clase que ya existía en la carpeta Filters, su nomenclatura indica que debe finalizar con el sufijo Attribute para poder ser utilizado como tal en MVC. Por lo tanto, le asignamos un nombre que termine con ese sufijo, una vez creada la clase, dado que se va a tratar de un ActionFilter, haremos que herede de la clase ActionFilterAttribute, añadiendo la cláusula using correspondiente (System.Web.Mvc).
Existen un buen número de filtros que el Framework nos proporciona por defecto, pero además, tenemos disponible la capacidad de crear nuestros propios filtros extendiendo una interfaz que se corresponde con uno de los 4 tipos de filtros que el Framework permite implementar. Estos cuatro tipos son los siguientes
Filtros de autorización. Son ejecutados antes de las acciones. Implementan la interfaz IAuthorizationFilter(AuthorizeAttribute, RequireHttpsAttribute, ValidateInputAttribute, ValidateAntiForgeryTokenAttribute, ChildActionOnlyAttribute)
Filtros de acción: Se ejecutan antes y después de invocar una acción. Implementan la interfaz IActionFilter(OnActionExcecuting, OnActionExecuted)
Filtros de resultados: Se ejecutan antes y después de ejecutar un ActionResult que devuelve algo desde una acción. Implementan IResultFilter(OnResultExcecuting, OnResultExecuted).
Filtros de error. Se ejecutan cuando se produce una excepción al ejecutar una acción, en el retorno de un resultado o bien en alguno de los filtros de dicha acción. Implementan la interfaz IExceptionFilter
Para crear un filtro personalizado podemos hacer dos cosas:
1) Heredar de la clase abstracta System.Web.Mvc.FilterAttribute e implementar uno o varios de los interfaces anteriores dependiendo de en qué momento queremos que nuestro código se ejecute y tomar el control de la acción.
2) Heredar de alguno de los filtros que ya existen en el Framework y sobreescribir sus métodos
Aplicando un filtro a toda la aplicación
Si en lugar de aplicar la operación de logging a una acción o controlador concreto quisiéramos que se aplicara a todas y cada una de las acciones de nuestra aplicación, tendremos que cambiar el lugar donde asignamos el filtro. Eliminaremos por lo tanto el atributo [Log4Net] de la acción actual y echamos un ojo al fichero que controla las acciones globales de la aplicación: global.asax.cs.
Observamos que una de las líneas de código es la encargada de registrar los filtros globales. Esto se realiza invocando el método FilterConfig.RegisterGlobalFilters. Si nos situamos sobre el método y pulsamos la tecla F12, nos llevará directamente al código de este método, que se encontrará en la carpeta App_Start/FilterConfig y tendrá el siguiente aspecto:
public class FilterConfig
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}
}
Como podremos imaginar, para añadir nuestro filtro bastará con añadir una línea similar a la existente indicando el filtro que creamos previamente (sin olvidarnos de la cláusula using), dejando el código de la siguiente manera:
public class FilterConfig
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
filters.Add(new Log4NetAttribute());
}
}
Con esta operación, cada vez que una acción sea ejecutada, nuestro filtro entrará en acción.
