Tips-Simplify your generic API

Below, I will use an example to share some tips for simplifying generic API design.How to filter out generic parameters that can be implicitly inferred when calling generic methods":

Original Design:

The system originally had such a static generic API:

 
Protected static propertyinfo <tproperty> registerproperty <Towner, tproperty> (expression <func <Towner, tproperty> propertylambdaexpression)
 

 

Usage:

 
VaR codeproperty = registerproperty <user, string> (E => E. Code );
 

 

It can be seen that although this method can implicitly infer the specific type of P from the parameter, it cannot deduce the specific type of T, so you need to explicitly specify the type of T.
Due to syntax characteristics, registerproperty <user> (E => E. code) to pass only one generic parameter to the API. When using this method, You Have To explicitly specify all generic parameters, that is, the above usage method.

Ling Guang Yixian:

How can we avoid passing the second generic parameter? After N days, we found that the following method can simplify the passed generic parameters:

Declare a generic class for this generic method:

 
Public class propertyregister <towner> {public static propertyinfo <tproperty> register <tproperty> (expression <func <Towner, tproperty> propertylambdaexpression) {towner onwer; tproperty propery; //...}}
 

At this time, the call method becomes:

 
VaR codeproperty = propertyregister <PBS>. Register (E => E. Code );
 

 

Is that good?

The advantage of this method is to simplify the customers of generic APIs.ProgramCallCode,Only explicitly pass in generic parameters that cannot be implicitly inferredNo additional generic parameters are input.
In this example, there are only two generic parameters. However, when you have more parameters and cannot infer that there is only one parameter, this method can be used.