& Lt; ABP framework & gt; verify the data transmission object and the data transmission object.

<ABP framework> verify the data transmission object and the data transmission object.

Document directory

 

Content of this section:

• Introduction
• Use Data Annotation
• Custom Verification
• Disable Verification
• Normalization

 

Introduction

The input of an application must be verified first. The input may come from the user or another application. In a web application, verification is usually performed twice: On the client and on the server, client verification is for the user experience. It is best to first check a form and display invalid input to the user. However, server verification is more decisive and necessary.

Server-side authentication is generally implemented in application services or controllers (typically, all services obtain data from the presentation layer ). An Application Service should check (verify) the input before using it. A basic structure is provided to automatically verify all three inputs of an application:

• All application service methods.
• Action of all Asp.net Core Mvc controllers.
• Actions of all Asp.net Mvc and Web Api controllers.

To disable verification, see disable verification.

 

Use Data Annotation

If we are developing a Task application service, it is used to create a Task and requires an input, as shown below:

public class CreateTaskInput{    public int? AssignedPersonId { get; set; }    [Required]    public string Description { get; set; }}

Here, the Description attribute is marked as Required, and AssingedPersonId is optional. In the System. ComponentModel. DataAnnotations namespace, there are many features (such as MaxLength, MinLenggth, RegularExpression ...). The implementation of the Task application service is as follows:

public class TaskAppService : ITaskAppService{    private readonly ITaskRepository _taskRepository;    private readonly IPersonRepository _personRepository;    public TaskAppService(ITaskRepository taskRepository, IPersonRepository personRepository)    {        _taskRepository = taskRepository;        _personRepository = personRepository;    }    public void CreateTask(CreateTaskInput input)    {        var task = new Task { Description = input.Description };        if (input.AssignedPersonId.HasValue)        {            task.AssignedPerson = _personRepository.Load(input.AssignedPersonId.Value);        }        _taskRepository.Insert(task);    }}

As you can see, the verification code is not written because the ABC automatically completes the verification. If the input is null, an AbpValidationException is thrown. Therefore, you do not need to write a null check. If any INPUT attribute is invalid, it will also throw an AbpValidationException.

This mechanism is similar to Asp.net Mvc verification, but please note that an application service class is not inherited from the Controller, It is a pure class, and can even be used outside of a web application.

 

Custom Verification

If the data annotation is not enough, you can implement the ICustomValidate interface, as shown below:

public class CreateTaskInput : ICustomValidate{    public int? AssignedPersonId { get; set; }    public bool SendEmailToAssignedPerson { get; set; }    [Required]    public string Description { get; set; }    public void AddValidationErrors(CustomValidatationContext context)    {        if (SendEmailToAssignedPerson && (!AssignedPersonId.HasValue || AssignedPersonId.Value <= 0))        {            context.Results.Add(new ValidationResult("AssignedPersonId must be set if SendEmailToAssignedPerson is true!"));        }    }}

The ICustomValidate interface defines the AddValidationErrors method. If a verification error occurs, we must add the ValidationResult object to the context. Results list. If necessary, you can use context. IocResolver to parse dependencies during verification.

In addition to ICustomValidate, ABP also supports the IValidatableObject interface. You can also implement it and perform additional custom verification. If you implement both interfaces, both interfaces will be called.

 

Disable Verification

For automatic verification classes (see the "Introduction" section), you can use these features to control Verification:

• DisableValidation feature: verification can be disabled on DTO classes, methods, or attributes.
• EnableValidation: In a disabled verification class, you can use this feature on methods to make input verification of the current method available.

 

Normalization

Sometimes we need to perform an additional operation after verification to sort out the DTO parameters. ABP defines the IShouldNormailize interface, including the Normalize method. If you implement this interface, the Normalize method is called after verification (before the method is called. Suppose we need to obtain the sorting direction (ascending or descending) from DTO. If not, we want to set a default value:

public class GetTasksInput : IShouldNormalize{    public string Sorting { get; set; }    public void Normalize()    {        if (string.IsNullOrWhiteSpace(Sorting))        {            Sorting = "Name ASC";        }    }}