ABP framework, abp

ABP framework, abp

Document directory

 

Content of this section:

• Introduction
  • Example
• Create a specification class
• Use conventions in warehousing
• Combination Statute
• Discussion
  • When to use
  • When not used

 

Introduction

The Protocol mode is a special software design mode. the business logic can be relinked to the business logic using the boolean logic (Wikipedia ).

In most cases, it defines reusable filters for entities or other business objects.

 

Example

In this section, we will see the necessity of the Protocol mode. This section is common and has nothing to do with the implementation of the ABP.

Assume that you have a service method to calculate the total number of customers, for example:

public class CustomerManager{    public int GetCustomerCount()    {        //TODO...        return 0;    }}

You may want to use a filter to obtain the number of customers. For example, if you have excellent customers (with a balance of more than $100,000) or filter customers based on the year of registration, you can create other methods, such: getPremiumCustomerCount (), GetCustomerCountRegisteredInYear (int year), GetPremiumCustomerCountRegisterdInYear (int year), and so on. When you have more conditions, you cannot create a combination for each scenario.

One solution to this problem is the protocol mode. We can create a separate method to obtain a parameter as a filter:

public class CustomerManager{    private readonly IRepository<Customer> _customerRepository;    public CustomerManager(IRepository<Customer> customerRepository)    {        _customerRepository = customerRepository;    }    public int GetCustomerCount(ISpecification<Customer> spec)    {        var customers = _customerRepository.GetAllList();        var customerCount = 0;                foreach (var customer in customers)        {            if (spec.IsSatisfiedBy(customer))            {                customerCount++;            }        }        return customerCount;    }}

Therefore, we can accept the implementationISpecification <Customer>Any object of the interface as a parameter, such:

public interface ISpecification<T>{    bool IsSatisfiedBy(T obj);}

Then we can callIsSatisfiedByTo check whether the customer meets the intent. Therefore, we can use different filters to call the same GetCustomerCount method without modifying the method itself.

In theory, this solution is good, but it can be improved more perfectly in C #. For example, getting all the customers from the database to check whether the given Conventions/conditions are met, this is not very efficient. In the following section, we will see the implementation of the ABP, which solves this problem.

 

Create a specification class

The following ISpecification interface is defined in the ABP interface:

public interface ISpecification<T>{    bool IsSatisfiedBy(T obj);    Expression<Func<T, bool>> ToExpression();} 

AddToExpression ()Method, which returns an expression to better combine IQueryable and expression Tree. Therefore, the database accepts a filter, we only need to simply transfer a protocol to a warehouse.

We usually start fromSpecification <T>Class inheritance, instead of directly implementing the ISpecification <T> interface. Specification class automatically implements the IsSatisfiedBy method. Therefore, we only need to define ToExpression and let us create some protocol classes:

//Customers with $100,000+ balance are assumed as PREMIUM customers.public class PremiumCustomerSpecification : Specification<Customer>{    public override Expression<Func<Customer, bool>> ToExpression()    {        return (customer) => (customer.Balance >= 100000);    }}//A parametric specification example.public class CustomerRegistrationYearSpecification : Specification<Customer>{    public int Year { get; }    public CustomerRegistrationYearSpecification(int year)    {        Year = year;    }    public override Expression<Func<Customer, bool>> ToExpression()    {        return (customer) => (customer.CreationYear == Year);    }}

As you can see, we just implement a simple lambda expression to define the conventions. Let's use these conventions to get the number of customers:

count = customerManager.GetCustomerCount(new PremiumCustomerSpecification());count = customerManager.GetCustomerCount(new CustomerRegistrationYearSpecification(2017));

 

Use conventions in warehousing

Now, we can optimize CustomerManager to accept filters in the database:

public class CustomerManager{    private readonly IRepository<Customer> _customerRepository;    public CustomerManager(IRepository<Customer> customerRepository)    {        _customerRepository = customerRepository;    }    public int GetCustomerCount(ISpecification<Customer> spec)    {        return _customerRepository.Count(spec.ToExpression());    }}

In this case, we can pass any conventions to the warehouse, so the Warehouse can use expressions as filters. in this example, CustomerManager is not necessary, so we can directly query the database using warehousing and conventions, but consider: We want to perform a business operation on a customer, we can use the Protocol and a domain service to specify the MERs to continue working.

 

Combination Statute

There is a powerful function: You can use And, Or, Not, And AndNot extension methods to combine the conventions. For example:

var count = customerManager.GetCustomerCount(new PremiumCustomerSpecification().And(new CustomerRegistrationYearSpecification(2017)));

We can even create a new statute based on the existing one:

public class NewPremiumCustomersSpecification : AndSpecification<Customer>{    public NewPremiumCustomersSpecification()         : base(new PremiumCustomerSpecification(), new CustomerRegistrationYearSpecification(2017))    {    }}

AndSpecificationIs a subclass that meets the condition only when both protocols are met. Then we can use NewPremiumCustomersSpecification, just like other protocols:

var count = customerManager.GetCustomerCount(new NewPremiumCustomersSpecification());

 

Discussion

Since the standard mode is older than the lambda expression of C #, we can compare it with the expression. some developers may think that the Protocol mode is no longer needed. We can directly pass expressions to a warehouse or domain service, such:

var count = _customerRepository.Count(c => c.Balance > 100000 && c.CreationYear == 2017);

Because the O & M expression is supported by the O & M service, this is a legal usage. In an application, you do not have to define or use any conventions, so you can inherit the expressions, what are the main points of the statute? Why, when should we consider using them?

 

When to use

Benefits of using the Protocol:

• Reusable: Imagine that you need to use "excellent customer" filtering in multiple places in your code. If you use expressions without creating a statute, what will happen if you need to modify the definition of "excellent customer" in the future (for example, if you want to change to a balance that ranges from $100,000 to 250,000 and contains other conditions, for example, if the customer has registered for more than 3 years, if you use the conventions, you only need to modify one class. If you use the same expression (copy/paste), you need to modify all the places used.
• Combination: You can combine multiple protocols to create new ones. This is another form of reuse.
• Naming: PremiumCustomerSpecification better expresses intent than a complex expression. Therefore, if you want an expression to become effective in your business, consider using the protocol.
• Testable: a protocol is a separate (and easy) testable object.

 

When not used

• No business expression: You can use no protocol when your business does not involve expressions or operations.
• Create a report: If you only create a report, you can use the original SQL, view, or other report tools instead of using the conventions. DDD does not care about report and underlying database storage to obtain query benefits and view performance.

 

Http://www.aspnetboilerplate.com/Pages/Documents/Specifications.