Shulou(Shulou.com)06/03 Report--

This article will explain in detail how to use data filters and data transfer objects in the ABP framework. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

Data filter (Data filters)

In database development, we generally use soft delete (soft-delete) mode, that is, we do not delete data directly from the database, but mark the data as deleted. Therefore, if the entity is soft deleted, it should not be retrieved in the application. To achieve this effect, we need to add SQL's Where condition IsDeleted = false to each query that retrieves the entity. It's a boring job, but it's easy to forget. Therefore, we should have an automatic mechanism to deal with these problems.

ABP provides a data filter (Data filters) that uses automated, rule-based filtering queries. ABP already has some predefined filters, and of course you can create your own filters.

Note: only for EntityFramework:ABP data filters are implemented only in EntityFramework. It cannot be used in other ORM tools yet. See other ORM chapters at the end of this article.

Predefined filter

1. Soft delete interface (ISoftDelete)

The soft delete filter (Soft-delete filter) filters entities queried from the database and is automatically applied (extracted from the result set). If the entity needs to be soft deleted, it needs to implement the ISoftDelete interface, which defines only one IsDeleted attribute. Example:

Public class Person: Entity, ISoftDelete {public virtual string Name {get; set;} public virtual bool IsDeleted {get; set;}}

The Person entity is not actually deleted from the database, and when it is deleted, the value of the IsDeleted property is set to true. ABP does this automatically when you use the IRepository.Delete method (you can set IsDeleted to true manually, but the Delete method is more natural and recommended).

When ISoftDelete is implemented, when you have retrieved the People list from the database, the deleted People entities will not be retrieved. Here is a sample class that uses person repositories to get all the People entities:

Public class MyService {private readonly IRepository _ personRepository; public MyService (IRepository personRepository) {_ personRepository = personRepository;} public List GetPeople () {return _ personRepository.GetAllList ();}

The GetPeople method only gets the Person entity whose IsDeleted = false (non-deleted state). All warehousing methods and navigation properties work properly. We can add some other Where conditions, Join... Wait. It will automatically add IsDeleted=false conditions to the generated SQL query statement.

Note: when is it enabled? the ISoftDelete filter is always enabled unless you disable it directly.

Reminder: if you implement the IDeletionAudited interface (which inherits from ISoftDelete), delete the creation time and deleted user Id, these will be handled automatically by ABP.

two。 Multi-lease interface (IMustHaveTenant)

If you create a multi-tenant application (storing all tenant data in a single database), you certainly don't want one tenant to see other tenant profiles. You can implement the IMustHaveTenant API in this case. The example is as follows:

Public class Product: IMustHaveTenant {public virtual int TenantId {get; set;} public virtual string Name {get; set;}}

IMustHaveTenant defines TenantId to distinguish between different tenant entities. ABP uses IAbpSession to get the current TenantId and automatically filter queries for the current tenant.

Note: when is it enabled? IMustHaveTenant is enabled by default. If the current user is not logged into the system or the current user is an administrative user (the administrative user is the most privileged user who can manage the data of all tenants and tenants), ABP automatically disables the IMustHaveTenant filter. Therefore, all tenant data can be retrieved by the application. Note that this has nothing to do with security, you should authenticate and authorize sensitive data.

3. Multi-lease interface (IMayHaveTenant)

If an entity class is shared by multiple tenants (tenant) and administrative users (host) (which means that the entity object may be controlled by tenants (tenant) or administrative users (host)), you can use IMayHaveTenantfilter. The IMayHaveTenant interface defines TenantId but it is a nullable nullable.

Public class Product: IMayHaveTenant {public virtual int? TenantId {get; set;} public virtual string Name {get; set;}}

When null, it means that this is an entity controlled by an administrative user (host). If it is a non-null value, it means that the entity is controlled by the tenant, and its ID value is TenantId. ABP uses the IAbpSession interface to get the current TenantId. IMayHaveTenant filters are not as common as IMustHaveTenant. But you may need it as a common structure for administrative users (host) and tenants (tenant).

When is it enabled? the IMayHaveTenant interface is always enabled unless you disable it directly.

Disable filter

You can call the DisableFilter method in the unit of work (unit of work) to disable a filter, as follows:

Var people1 = _ personRepository.GetAllList (); using (_ unitOfWorkManager.Current.DisableFilter (AbpDataFilters.SoftDelete)) {var people2 = _ personRepository.GetAllList ();} var people3 = _ personRepository.GetAllList ()

The DisableFilter method gets one or more filter names, all of type string. AbpDataFilters.SoftDelete is a constant string that contains the soft delete filter of the ABP standard.

People2 can also obtain People entities that have been marked for deletion, while people1 and people3 will be the only People entities that are not marked for deletion. With using syntax, you can disable filters that fall within its control (Scope). If you do not use the using syntax, this filter will be disabled until the unit of work (unit of work) ends or is enabled again. (meaning: if you use the "using" keyword to declare, the filter is enabled; after the current unit of work (unit of work) ends, the filter is disabled. If you do not declare it with the "using" keyword, the default filter is disabled, and you can enable the filter manually.)

You can inject IUnitOfWorkManager and use it in the above example. Similarly, you can use the CurrentUnitOfWork property as an easy way to use the application service (it inherits from the ApplicationService class).

Note about using syntax: if the filter is enabled before you call the DisableFilter method and cooperate with the using syntax, the filter will be disabled and will automatically be enabled at the end of the using syntax. But if the filter is disabled before the using syntax, the DisableFilter method does not actually do any expression, and the filter remains disabled even after the end of the using syntax.

Enable filter

You can use the EnableFilter method to enable the filter in the unit of work (unit of work), just like the DisableFilter method (both positive and negative). EnableFilter also returns disposable to automatically re-disable the filter.

Set filter parameters

Filters can be parameterized (parametric). The IMustHaveTenant filter is a model for such filters because the Id of the current tenant (tenant) is determined at execution time. For these filters, we can change the value of the filter if necessary. Examples are as follows:

CurrentUnitOfWork.SetFilterParameter ("PersonFilter", "personId", 42)

Another example is as follows: set the tenantID value of the IMayHaveTenant filter:

CurrentUnitOfWork.SetfilterParameter (AbpDataFilters.MayHaveTenant, AbpDataFilters.Parameters.TenantId, 42)

Custom filter

To create a custom filter and integrate it into ABP, we first need to define an interface that will be implemented by the entity that uses the filter. Suppose we want to filter automatically by PersonId. The example is as follows:

Public interface IHasPerson {int PersonId {get; set;}}

Then we can implement this interface on our entity, as shown in the following example:

Public class Phone: Entity, IHasPerson {[ForeignKey ("PersonId")] public virtual Person Person {get; set;} public virtual int PersonId {get; set;} public virtual string Number {get; set;}}

Because ABP uses EntityFramework.DynamicFilters as a filter, we use its rule to define the filter. In our DbContext class, we override OnModelCreating and define a filter as shown in the following example:

Protected override void OnModelCreating (DbModelBuilder modelBuilder) {base.OnModelCreating (modelBuilder); modelBuilder.Filter ("PersonFilter", (IHasPerson entity, int personId) = > entity.PersonId = = personId, 0);

The PersonFilter filter is a unique filter name here. Then there is the parameter definition of the filter interface and the personId filter parameter (not necessarily required, if the filter is non-parameterized (parametric)), and the last parameter is the default value of personId.

As a final step, we need to register this filter to the ABP unit of work (unit of work) system and set the location in our module's PreInitialize method.

Configuration.UnitOfWork.RegisterFilter ("PersonFilter", false)

The first parameter is the unique name we just defined, and the second parameter indicates whether the filter is enabled or disabled by default. After declaring these parametric filters, we can specify its value during execution to manipulate the filter.

Using (CurrentUnitOfWork.EnableFilter ("PersonFilter")) {CurrentUnitOfWork.SetFilterParameter ("PersonFilter", "personId", 42); var phone = _ phoneRepository.GetAllList (); / /.}

We can get the personId from some data sources without having to write it in the program code. The above example is to be able to program the filter. The filter can have 0 to more parameters. If it is a filter with no parameters, it does not need to set the value of the filter. Similarly, if it is enabled by default, it does not need to be enabled manually (of course, we can also disable it).

EntityFramework.DynamicFilters file: for more information about dynamic data filters, you can see its file https://github.com/jcachat/EntityFramework.DynamicFilters on git

We can create a custom filter for security, active / passive entities, multi-tenancy. Things like that.

Other object-relational mapping tools

ABP data filters are implemented only on Entity Framework. It is not yet available for other ORM tools. However, in fact, you can mimic this pattern to other cases where warehousing is used to obtain data. In this case, you can create a custom repository and override the GetAll method, and modify other data retrieval methods together if necessary.

Data transfer object (DTOs)

Data transfer objects (Data Transfer Objects) are used for data transmission in the application layer and presentation layer.

The presentation layer passes in the data transfer object (DTO) to invoke an application service method, and then the application service executes some specific business logic through the domain object and returns DTO to the presentation layer. In this way, the presentation layer and the domain layer are completely separated. In applications with good layering, the presentation layer does not directly use domain objects (repositories, entities).

The role of data transfer objects

Creating a DTO for each application service method seems like a tedious and time-consuming task. But if you use them correctly, this will save your project. Why is that?

1. Abstract domain layer (Abstraction of domain layer)

In the presentation layer, the data transfer object abstracts the domain object effectively. In this way your layers will be properly isolated. Even when you want to completely replace the presentation layer, you can continue to use the existing application layer and domain layer. Instead, you can rewrite the domain layer and modify the database structure, entities, and ORM framework, but you don't need to make any changes to the presentation layer, as long as your application layer hasn't changed.

two。 Data hiding (Data hiding)

Imagine that you have a User entity with attributes Id, Name, EmailAddress, and Password. If the return type of the GetAllUsers () method of UserAppService is List. This way anyone can check everyone's password, even if you don't print it on the screen. It's not just a security issue, it's also about data hiding. The application service should only return what is needed in the presentation layer, just right.

3. Serialization & lazy loading (Serialization & lazy load problems)

When you return data (objects) to the presentation layer, the data may be serialized. For example, in an Action that returns a MVC of Json, your object needs to be serialized into JSON and sent to the client. Returning the entity directly to the presentation layer may cause trouble.

In a real project, entities refer to other entities. The User entity references the Role entity. So, when you serialize User, Role will also be serialized. And Role also has a List and Permission also quotes PermissionGroup and so on. . Can you imagine that these objects will be serialized? This is likely to cause the entire database data to be serialized unexpectedly. So how to solve it? Mark attributes as non-serializable? No, because you don't know when a property should be serialized and when it shouldn't be serialized. So in this case, it is a good choice to return a data transfer object that can be securely serialized and customized.

Almost all ORM frameworks support lazy loading. It is loaded only when you need to load the entity. For example, the User type refers to the Role type. When you get User from the database, the Role property is not populated. Role is loaded from the database only when you read the Role property for the first time. Therefore, when you return such an entity to the presentation layer, it is easy to cause side effects (loading from the database). If the serialization tool reads the entity, it will read all the properties recursively so that your entire database will be read.

There are more problems with using entities in the presentation layer. The best solution is that the presentation layer should not reference any assembly that contains the domain layer.

DTO convention & verification

ABP provides powerful support for data transfer objects. It provides some related (Conventional) types & interfaces and provides recommendations for DTO naming and usage conventions. When you use DTO,ABP like here, it will automate some tasks and make it easier for you.

An example (Example)

Let's look at a complete example. We want to write an application service method to search people based on name and return a list of people. The Person entity code is as follows:

Public class Person: Entity {public virtual string Name {get; set;} public virtual string EmailAddress {get; set;} public virtual string Password {get; set;}}

First, we define an application service interface:

Public interface IPersonAppService: IApplicationService {SearchPeopleOutput SearchPeople (SearchPeopleInput input);}

ABP recommends that naming input/ouput objects is similar to MethodNameInput/MethodNameOutput, where Input and Output need to be defined separately for each application service method. Even if your method receives or returns only one value, it is best to create the corresponding DTO type. In this way, your code will be more extensible, and you can add more properties without changing the signature of the method, which will not destroy the existing client application.

Of course, the return value of the method may be void, and then you add a return value without destroying the existing application. If your method does not require any parameters, then you do not need to define an Input Dto. But creating an Input Dto may be a better solution, because the method may require a parameter in the future. Of course, it's up to you to create it or not. The Input and Output DTO types are defined as follows:

Public class SearchPeopleInput: IInputDto {[StringLength (40, MinimumLength = 1)] public string SearchedName {get; set;}} public class SearchPeopleOutput: IOutputDto {public List People {get; set;}} public class PersonDto: EntityDto {public string Name {get; set;} public string EmailAddress {get; set;}

Verification: as a convention, Input DTO implements the IInputDto interface and Output DTO implements the IOutputDto interface. When you declare the IInputDto parameter, ABP will automatically verify the validity of the method before it is executed. This is similar to the ASP.NET MVC authentication mechanism, but note that the application service is not a Controller. ABP intercepts it and checks the input. Check the DTO validation (DTO Validation) documentation for more information. EntityDto is a simple type that has the same Id attribute as an entity. You can use the generic version of your entity Id if it is not int. EntityDto also implements the IDto interface. You can see that PersonDto does not contain the Password attribute because the presentation layer does not need it.

Before going any further, let's implement IPersonAppService:

Public class PersonAppService: IPersonAppService {private readonly IPersonRepository _ personRepository; public PersonAppService (IPersonRepository personRepository) {_ personRepository = personRepository;} public SearchPeopleOutput SearchPeople (SearchPeopleInput input) {/ / get entity var peopleEntityList = _ personRepository.GetAllList (person = > person.Name.Contains (input.SearchedName)); / / convert to DTO var peopleDtoList = peopleEntityList .Select (person = > new PersonDto {Id = person.Id, Name = person.Name, EmailAddress = person.EmailAddress}). ToList (); return new SearchPeopleOutput {People = peopleDtoList};}}

We get the entity from the database, convert the entity to DTO, and return output. Note that we did not manually check the validity of the Input data. ABP automatically validates it. ABP even checks whether Input is null and throws an exception if it is null. This prevents us from manually checking the validity of the data in each method.

But you probably don't like to manually convert Person entities to PersonDto. This is really a boring job. This is especially true when Peson entities contain a large number of attributes.

Automatic mapping between DTO and entities

Fortunately, there are some tools that can make mapping (transformation) very simple. AutoMapper is one of them. You can add it to your project through nuget. Let's use AutoMapper to override the SearchPeople method:

Public SearchPeopleOutput SearchPeople (SearchPeopleInput input) {var peopleEntityList = _ personRepository.GetAllList (person = > person.Name.Contains (input.SearchedName)); return new SearchPeopleOutput {People = Mapper.Map (peopleEntityList)};}

That's the whole code. You can add more attributes to entities and DTO, but the conversion code remains the same. Before that, there's only one thing you need to do: mapping.

Mapper.CreateMap ()

AutoMapper creates the code for the mapping. In this way, dynamic mapping does not become a performance problem. It's so fast and convenient. AutoMapper creates the PersonDto from the Person entity and assigns values to the attributes of the PersonDto according to the naming convention. Naming conventions are configurable and flexible. You can also customize the mapping and use more features, check the AutoMapper documentation for more information.

Use attributes and extension methods to map (Mapping using attributes and extension methods)

ABP provides several attributes and extension methods to define mappings. To use it you need to add Abp.AutoMapper to your project through nuget. There are two ways to map using the AutoMap feature (attribute), one is to use AutoMapFrom and AutoMapTo. The other is to use the MapTo extension method. Examples of defining mappings are as follows:

[AutoMap (typeof (MyClass2))] / / define mapping (so there are two ways to map) public class MyClass1 {public string TestProp {get; set;}} public class MyClass2 {public string TestProp {get; set;}}

Then you can map through the MapTo extension method:

Var obj1 = new MyClass1 {TestProp = "Test value"}; var obj2 = obj1.MapTo (); / / creates a new MyClass2 object and assigns the value of obj1.TestProp to the TestProp property of the new MyClass2 object.

The above code creates a new MyClass2 object based on MyClass1. You can also map existing objects, as shown below:

Var obj1 = new MyClass1 {TestProp = "Test value"}; var obj2 = new MyClass2 (); obj1.MapTo (obj2); / / set the properties of obj2 according to obj1

Secondary interfaces and types

ABP also provides some auxiliary interfaces that define commonly used standardized attributes.

ILimitedResultRequest defines the MaxResultCount attribute. So you can implement this interface on your Input DTO to limit the number of result sets.

IPagedResultRequest extends ILimitedResultRequest by adding the SkipCount attribute. So we implement this interface in SearchPeopleInput for paging:

Public class SearchPeopleInput: IInputDto, IPagedResultRequest {[StringLength (40, MinimumLength = 1)] public string SearchedName {get; set;} public int MaxResultCount {get; set;} public int SkipCount {get; set;}}

For paging requests, you can use the Output DTO that implements IHasTotalCount as the return result. Standardized attributes help us create reusable code and specifications. You can view other interfaces and types under the Abp.Application.Services.Dto namespace.

This is the end of this article on "how to use data filters and data transfer objects in the ABP framework". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it out for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.