[Entlib] Microsoft Enterprise Library 5.0 learning path-Step 9, using policyinjection module for AOP-PART1-basic usage Introduction

Continue to learn from Microsoft enterprise database 5.0. Today we will mainly introduce the policyinjection module of the enterprise database. This module is created to facilitate the use of AOP in projects, this article describes the information of the policyinjection module, the built-in matching rules, and the use of the built-in processing module.

 

1. Introduction to the basic information of the policyinjection Module

Policyinjection is a module officially introduced in Enterprise Library 3.0, referred to as piab (Policy injection Application Block ), the main function of this module is to facilitate AOP in project development to simplify development content. I have already introduced AOP to many friends in the garden. I will not repeat it here. If you do not know about it, you can go to Zhang Yi's article.ArticleMedium learning: AOP technical foundation.

In. net actually has many mature AOP projects, such as postsharp, spring.net, and JBoss. The Enterprise Library piab I introduced today also implements the AOP function, however, piab can be well combined with several other major modules in the Enterprise Library, such as logging, exception, and security, you can implement the AOP function immediately with simple configuration.

Since there are few piab articles in China, you can refer to the series of blog articles "enterlib piab deep analysis" written by artech (However, artech wrote earlier, but it was written in 3.1. At that time, the enterprise database version was 5.0, so there are many differences with the current enterprise database version, however, its principle has not changed. It is worth noting that)

If you want to know how to configure piab in the enterprise database and how to use it, please refer to the policy injection Application Block written by huangcong.

The configuration diagram of the policyinjection module shows that the specific AOP policy is in the middle, and the verification rules required by this AOP policy are on the left, on the right is the specific call processing operation of this AOP policy.

Note:

1. It is best to use only one verification rule for each policy configuration. If more than one verification rule is used, the AOP effect cannot be achieved.

2. The class to implement the AOP policy must implement the class externalbyrefobject or this class must implement an interface.

 

II. Introduction to the built-in verification rules of the policyinjection Module

The policyinjection module inherits the excellent ease-of-use and scalability of the enterprise database. Like other modules, it has many built-in verification rules that are convenient for our developers, there are 11 verification rules:

1. Assembly matching rule --ProgramSet verification rules

2. custom attribute matching rule -- custom feature verification rules

3. Custom matching rule-custom verification rules

4. member name matching rule -- name verification rules

5. Method signature matching rule -- Method signature verification rules

6. namespace matching rule -- namespace verification rules

7. Parameter type matching rule -- parameter type verification rules

8. Property Matching Rule -- property verification rules

9. Return type matching rule -- return type verification rules

10. Tag attribute matching rule -- Tag feature verification rules

11. Type matching rule -- type verification rules

 

The following describes how to use these built-in verification rules:

1. Assembly matching rule-assembly verification rules

This verification matches the Set Name and achieves the effect of AOP. This verification rule only receives one parameter: Assembly name.

The Assembly name parameter can receive the following types of strings:

1. Name and version, name and version number

For example, Microsoft. Practices. enterpriselibrary. Common, version = 5.0.414.0

2. Name, version, and curlture

For example, Microsoft. Practices. enterpriselibrary. Common, version = 5.0.414.0, culture = neutral

3. Full assembly name, full Assembly name, but cannot contain the suffix ". dll"

For example, aopassembly

 

2. custom attribute matching rule -- custom property verification rules and custom matching rule -- custom verification rules

These two verifications are reserved for developers. I will introduce these two verification rules in the next article.

 

3. member name matching rule -- name verification rules

This verification rule is also relatively simple. It verifies the class or class members that match the configuration name. This verification rule only receives one parameter: Member names (wildcard characters supported)

See the followingCodeTo implement the AOP policy when executing the test method, I only need to inherit the class from the marshalbyrefobject, and then configure it in the Enterprise Library Configuration tool to add the member name matching rule, add the test method name to the configuration tool:

 
Public class myaop: externalbyrefobject {public void test (string aa) {console. writeline (AA );}}
 

The configuration diagram is as follows:

4. Method signature matching rule -- Method signature verification rules

This verification rule is special. It adopts the AOP policy based on the method signature. The method signature is generally test (string aa)

This verification rule receives two parameters:

1. Match: name of the matching method. This match can receive wildcard matching, "*" (Indicating multiple characters), "?" (Represents zero or one character), "[]" (by writing the character range in)

For example:

Test * supports matching of methods such as Testa and testab.

Test ?, Supports matching of methods such as test and Testa.

Test [1-9], supports matching of methods such as test1 and Test2

2. parameters: Specifies the parameter name and type for the method parameter list.

It should be noted that the parameter type should not be from the "type selector" next to the configuration tool, because the parameter type selected through this type selector will contain useless information such as the assembly version number, this will cause the AOP policy to fail. Therefore, we recommend that you use the handwriting type.

For example, name: AA, parameter type name: system. String

The instance code is as follows:

 
Public class aopclass: externalbyrefobject {public void test (string aa) {console. writeline (AA);} public void Test2 (string aa) {console. writeline (AA);} public void test3 (string aa) {console. writeline (AA );}}
 

The configuration diagram is as follows:

 

5. namespace matching rule -- namespace verification rules

This verification rule is similar to the above member name matching rule, except that the namespace matching rule matches the namespace verification. This verification rule receives a parameter: namespaces (wildcards supported)

This parameter namespaces is a set and can be configured with the namespace for the AOP policy.

For example, aopassembly. Test

It should be noted that, if the name to be matched is not a root-level namespace, such as aopassembly. Test, you cannot simply write the root namespace aopassembly, which will not match.

The configuration diagram is as follows:

 

6. Parameter type matching rule -- parameter type verification rules

This verification is to match the method parameters and receive a parameter parameters type

This parameter parameters type is also a set. You can configure the parameter information for the AOP policy.

This parameters type mainly has two sub-parameters: parameter kind (parameter direction, input, output, inputoroutput and returnvalue5 types) and match (matching name)

For example, parameter kind: input, Match: bb

The sample code is as follows:

Public void assemblyaop (string bb) {console. writeline (bb );}
 

The configuration diagram is as follows:

 

7. Return type matching rule -- return type verification rules

This type verification rule matches the type returned by the method and receives a return type parameter.

This return type can be a type name or a class name

For example, system. String, class1

The sample code is as follows:

 
Public String relacestring (string aa) {AA = "replace"; return AA ;}
 

The configuration diagram is as follows:

 

8. Tag attribute matching rule -- Tag feature verification rules

This verification rule is based on Attribute-tagattribute, which receives a parameter: Tag attribute.

This parameter tag attribute is a feature parameter configured in a class, method, or attribute (Wildcards are supported ).

Note that the tag attribute feature class requires the introduction of the namespace: using Microsoft. Practices. Unity. interceptionextension;

The sample code is as follows:

 
[Tag ("Test2")] public void Test2 (string aa) {console. writeline (AA );}
 

 

9. Type matching rule -- type verification rules

This verification is performed based on the type and receives a list parameter: type matches.

Add the type to be matched in type matches to enable the class name or the complete name containing the namespace.

For example, aoptest, aopassembly. aoptest

The configuration diagram is as follows:

 

The above is all the content in this article. This article mainly introduces how to use the built-in verification rules of the policyinjection module of the enterprise database and some precautions for using the built-in verification rules, next, we will introduce custom rules and built-in processing operations.

 

Index of a series of articles on the learning path of Microsoft enterprise database 5.0:

Step 1: getting started

Step 2: Use the vs2010 + data access module to create a multi-database project

Step 3: Add exception handling to the project (record to the database using custom extension)

Step 4: Use the cache to improve the website's performance (entlib caching)

Step 5: Introduce the entlib. validation module information, the implementation level of the validators, and the use of various built-in validators-Part 1

Step 5: Introduce the entlib. validation module information, the implementation level of the validators, and the use of various built-in validators-Part 1

Step 5: Introduce the entlib. validation module information, the implementation level of the validators, and the use of various built-in validators-Part 2

Step 6: Use the validation module for server-side data verification

Step 7: Simple Analysis of the cryptographer encryption module, custom encryption interfaces, and usage-Part 1

Step 7: Simple Analysis of the cryptographer encryption module, custom encryption interfaces, and usage-Part 2

Step 8. Use the configuration setting module and other methods to classify and manage enterprise database configuration information

Step 9: Use the policyinjection module for AOP-PART1-basic usage

Step 9: Use the policyinjection module for AOP-PART2-custom matching rule

Step 9: Use the policyinjection module for AOP-PART3 -- Introduction to built-in call Handler

Step 9: Use the policyinjection module for AOP-PART4 -- create a custom call handler to achieve user operation Logging

Step 10: Use unity to decouple your system-Part1-Why use unity?

Step 10: Use unity to decouple your system-Part2-learn how to use Unity (1)

Step 10. Use unity to decouple your system-Part2-learn how to use Unity (2)

Step 10: Use unity to decouple your system-Part2-learn how to use Unity (3)

Step 10: Use unity to decouple your system-Part3-dependency Injection

Step 10: Use unity to decouple your system-part4 -- unity & piab

Extended learning:

Extended learning and dependency injection in libraries (rebuilding Microsoft Enterprise Library) [go]