ABP Application Layer--Parameter validation

ABP Application Layer--Parameter validation

DDD-based Modern ASP.--ABP Series 17, ABP application Layer-Parameter Validation

The ABP is "ASP. Boilerplate Project (ASP. NET Template project) "for short.

ABP's official website : http://www.aspnetboilerplate.com

ABP's Open source project on GitHub : https://github.com/aspnetboilerplate

The application's input data should first be checked for validity. The data entered can be submitted by the user or another application. In Web applications, there are typically 2 data validation checks: Both client-side and service-end validation. The client's test is primarily to enable the user to have a good user experience. First, it is best to verify the validity of the form input on the client and that the input of those fields presented to the client is invalid. However, server-side validation is more critical and not missing (do not just do client-side validation without server-end validation).

Server-side inspection is usually performed by the application Service (layer), and the method in the Application Service (layer) first verifies the validity of the data before using the validated data. The ABP infrastructure provides a way to automatically verify the validity of input data.

The Application Service (layer) method obtains a data transfer object (DTO) as input. The ABP has a ivalidate interface that allows the DTO to verify the validity of the data by implementing this interface. Since Iinputdto is extended from Ivalidate, you can implement the Iinputdto interface directly to verify the validity of the data transfer object (DTO).

Using data annotations

The ABP provides the characteristics of the data annotations. Let's say we're developing an app service that creates a task and gets an input, see the following example:

public class createtaskinput:iinputdto{public    int? Assignedpersonid {get; set;}    [Required]    public string Description {get; set;}}

Here, the Description property is marked as Required. The Assignedpersonid is optional. There are many such features in the System.ComponentModel.DataAnnotations namespace (for example: MaxLength, MinLength, RegularExpression, and so on).

In the System.ComponentModel.DataAnnotations namespace, see implementation of Task application service

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, there is no data validation code written here (that is, validation of the description attribute) because the ABP automatically verifies the validity of the data. The ABP also verifies that the input data is null. A Abpvalidationexception exception is thrown if it is empty. So you don't have to write code that verifies whether the data is a null value. If any of the property's input data is invalid, it will also throw the same exception.

This mechanism is similar to the validation feature of ASP. Note: The Application service class here is not inherited from controller, it is a common class used in Web applications.

Custom inspection

If the way data annotations do not meet your needs, you can implement the Icustomvalidate interface, see the following example:

public class Createtaskinput:iinputdto, icustomvalidate{public    int? Assignedpersonid {get; set;}    public bool Sendemailtoassignedperson {get; set;}    [Required]    public string Description {get; set;}    public void Addvalidationerrors (list<validationresult> results)    {        if (Sendemailtoassignedperson & & (! Assignedpersonid.hasvalue | | Assignedpersonid.value <= 0))        {            results. ADD (New Validationresult ("Assignedpersonid must be set if Sendemailtoassignedperson is true!"));}}}    

The Icustomvalidate interface declares a addvalidationerrors method that can be implemented. Here we have a property called Sendemailtoassignedperson. If the property is true, the Assignedpersonid property is verified to be valid, otherwise the property can be empty. If there are validation errors, we must add these validation results to the result collection. (That is, add validationresult to results)

Set default values

After verifying the validity of the data, we need to perform an additional action to defragment the DTO parameters. The ABP defines a ishouldnormalize interface that declares a normalize method. If you implement this interface, the normalize method is called after verifying the validity of the data. Suppose our dto needs a sort of data in the direction. If this sorting property is not provided with data, then in normalize we can set a default value for sorting.

public class Gettasksinput:iinputdto, ishouldnormalize{public    string Sorting {get; set;}    public void Normalize ()    {        if (string. Isnullorwhitespace (sorting))        {            sorting = "Name ASC";}}    }

I hope that more domestic architects will be able to focus on the ABP project, and perhaps it will help you, perhaps with your participation, this project can develop better.

Welcome to add ABP Architecture Design Exchange QQ Group: 134710707

Click here to go to the ABP series articles General Catalogue

ABP Application Layer--Parameter validation