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

In this issue, the editor will bring you an example analysis of aspect-oriented programming and implementation in Spring2.5.6. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

Aspect-oriented programming (AOP) makes up for the shortcomings of object-oriented programming (OOP) by providing another way to think about program structure. The key unit of modularization in OOP is the classes, while the modular unit in AOP is the aspect. Aspects can modularize concerns, such as transaction management for crosscutting multiple types and objects. (in AOP terminology, it is often referred to as crosscutting concerns.) AOP framework is an important part of Spring. But the Spring IoC container does not rely on AOP, which means you have the right to choose whether or not to use AOP,AOP as a supplement to the Spring IoC container, making it a powerful middleware solution.

The role of AOP in Spring Framework provides declarative enterprise services, especially as an alternative to EJB declarative services. The most important service is declarative transaction management. Allows users to implement custom sections and use AOP to improve the use of OOP. In business systems, there are always some service logic that has nothing to do with business logic (such as logging, security verification, transaction management, etc.).

In the traditional programming method, the code of these service logic will always infiltrate into the code of business logic, making the service logic and business logic completion completely mixed together, which will make the business system more complex. It is not suitable for the start of the current large-scale business system. As shown in the figure:

The picture shows that service logic and business logic are intertwined under the traditional programming mode.

After the introduction of AOP, the service logic is collected and designed as independent and reusable aspects, which can be woven on top of the business logic that requires the service. In this way, these service logic can be flexibly applied to the business system, and do not care about their existence when invoking the business logic code. As shown in the picture.

The picture shows: after the introduction of AOP, the service logic and business logic are separated.

To understand AOP, you must first understand the following terms of AOP:

L Section (Aspect):

The modularization of a concern, which may crosscut multiple objects. Transaction management is a good example of crosscutting concerns in J2EE applications.

L connection point (Joinpoint):

At a specific point in the execution of a program, such as when a method is called or when an exception is handled. In Spring AOP, a join point always represents the execution of a method.

L notice (Advice):

An action performed at a specific join point of a section. This includes different types of notifications such as "around", "before", and "after" (the types of notifications are discussed in a later section). Many AOP frameworks (including Spring) use interceptors as notification models and maintain a chain of interceptors centered on join points.

L pointcut (Pointcut):

The assertion that matches the join point. The notification is associated with a pointcut expression and runs on a join point that satisfies that pointcut (for example, when a method with a particular name is executed). How pointcut expressions match join points is the core of AOP: Spring uses AspectJ pointcut syntax by default.

L introduce (Introduction):

Used to declare additional methods or properties for a type (also known as a connection type declaration (inter-type declaration)). Spring allows the introduction of new interfaces (and a corresponding implementation) to any proxied object. For example, you can use introduction to make a bean implement the IsModified interface to simplify the caching mechanism.

L Target object (Target Object):

An object notified by one or more aspects. Also known as the advised object.

L AOP Agent (AOP Proxy):

Objects created by the AOP framework to implement aspect contracts (such as notifying method execution, etc.). In Spring, the AOP agent can be a JDK dynamic agent or a CGLIB agent.

L weave (Weaving):

Spring, like other pure Java AOP frameworks, completes weaving at runtime.

Declaration:

Notification type:

Before advice: a notification that is executed before a join point, but this notification does not prevent the execution process before the join point (unless it throws an exception).

Post notification (After returning advice): a notification that is executed after a connection point is completed normally: for example, a method returns normally without throwing any exceptions.

Exception notification (After throwing advice): a notification that is executed when a method throws an exception to exit.

Final notification (After (finally) advice): a notification executed when a connection point exits (whether it is a normal return or an abnormal exit).

Around Advice: a notification that surrounds a join point, such as a method call. This is a large type of notification. A surround notification can complete custom behavior before and after a method call. It also chooses whether to continue execution of the join point or simply return its own return value or throw an exception to end execution.

The concept of matching join points through pointcuts is the key to AOP, which makes AOP different from other old technologies that only provide interception capabilities. The pointcut enables notifications to correspond independently to the object-oriented hierarchy. For example, a surround notification that provides declarative transaction management can be applied to a set of methods that span multiple objects (for example, all business operations at the service layer).

Spring AOP implementation

In Spring2.5.6, there are two common ways to implement AOP:

* *, which is based on the implementation of xml configuration file.

The second is based on annotations.

So do you use @ AspectJ (annotations) or XML in Spring AOP? Do they have the advantages and disadvantages of being tall or not?

If you are not running on Java 5, the XML style is * choice. For projects that use Java 5, there are many tradeoffs to consider.

XML style is more accustomed to existing Spring users. It can be used at any Java level (refer to named join points within the join point expression, although it also requires Java 5 +) and is supported by pure POJO. XML is a good choice when using AOP as a tool to configure enterprise services. (a good example is that when you think the join point expression is part of your configuration, you may want to change it separately.) for the XML style, you can clearly show which aspects exist in the system from your configuration.

The XML style has two drawbacks.

* is that it cannot completely encapsulate the implementation of the requirements into one location. According to the DRY principle, every piece of knowledge in the system must have a single, unambiguous and authoritative representation. When using the XML style, the knowledge of how to implement a requirement is divided into the declaration of the supporting class and the XML configuration file. When using the @ AspectJ style, only a single module-aspect-information is encapsulated.

The second is that the XML style has more limitations than the @ AspectJ style can express: only the "singleton" aspect instance model is supported, and the declaration of named join points cannot be combined in XML. For example, in the @ AspectJ style, we can write something like this:

Xml code

@ Pointcut (execution (* get* ()) public void propertyAccess () {} @ Pointcut (execution (org.xyz.Account+ * (..) Public void operationReturningAnAccount () {} @ Pointcut (propertyAccess () & & operationReturningAnAccount ()) public void accountPropertyAccess () {}

The first two join points can be declared in the XML style:

Xml code

Expression= "execution (org.xyz.Account+ * (..)" / >

Expression= "execution (org.xyz.Account+ * (..)" / >

But you can't combine these to define accountPropertyAccess connection points.

The @ AspectJ style supports other instance models and richer combinations of join points. It has the advantage of keeping the section as a module unit. Another advantage is that the @ AspectJ aspect can be understood by both Spring AOP and AspectJ-so if you think later that you need the ability of AspectJ to implement additional requirements, you can easily migrate to an AspectJ-based approach. All in all, we prefer the @ AspectJ style as long as you have the facets to do more than simply "configure" enterprise services.

Concluding remarks

We can mix the following styles of aspect definitions: @ AspectJ-style aspects using automatic proxies, schema-defined-style aspects, and declarative advisor, or even Spring 1.2-style proxies and interceptors. Because the aspects of the above styles all use the same underlying mechanism, they can coexist well.

The above is the example analysis of aspect-oriented programming and implementation in Spring2.5.6 shared by Xiaobian. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.