Home >Backend Development >PHP Tutorial >PHP Notes: Application of AOP_PHP Tutorial
PHP Notes: Application of AOP_PHP Tutorial
- WBOYOriginal
- 2016-07-21 15:12:00845browse
Introduction
Have you heard of AOP (Aspect Oriented Programming) before? Although it does not seem to be used too much in PHP, AOP is widely used in enterprise-level development. I will use this article to introduce you to AOP in PHP.
This article mainly explains the concept of AOP.
What is AOP?
In application development, we often find that many functions are needed, and these functions need to be scattered at multiple points in the code, but these points actually have no connection with the actual business. For example, before performing some special tasks, it is necessary to ensure that the user is logged in. We call these special people "cross-cutting concerns". Let us use Wikipedia to understand the definition of "cross-cutting concerns" (horizontal relationship) .
In computer science, "cross-cutting concerns" refers to "aspect (or direction) programming". These relationships are not well decomposed from other systems (framework design or some implementation) so that there is duplication of code, meaningful dependencies in the system, or both.
Now you should have a basic understanding of "horizontal relationships", let's see what they look like in code?
Assume a scenario where you are the editor of a blog site. You need to log in to the site and then create posts, verify posts, edit posts, etc. If you are not logged in, you should go directly to the login screen. In order to ensure that these behaviors are safe, any of the above operations need to be effectively verified, the code is as follows.
class BlogPost extends CI_Controller
{
public function createPost() {
Messages::notifyAdmin ();
}
}
public function approvePost() {
if (!Authentication::checkAuthentication()) {
// redirect to login
} else {
}
}
public function editPost() {
if (!Authentication::checkAuthentication()) {
// redirect to login
}
else {
}
public function viewPost() {
// ...
}
}
Looking at the above code, you will find that checkAuthentication() is called before each method, because these actions require the user to log in before they can be performed. There is also notifyAdmin() to identify whether it is an administrator account so that new posts can be created. Did you see that there is a lot of "duplicated code", and the BlogPost class should only be responsible for managing posts. Verification and identification should be separated. We violated the "Single Responsibility Principle".
The single responsibility principle tells that each class should have only a single responsibility (task), and the entire responsibility should be encapsulated in one class. All services should be distributed in a rigorous and balanced manner according to responsibilities.
So far, we can understand what AOP means. Horizontal aspect relationships are grouped into a class, which we call "aspect". The process of separating aspect-oriented relationships from our core code is called Aspect Oriented Programming.
AOP professional terminology
There are many conditions specifically used to explain the characteristics of AOP. Understanding these conditions will be your key to successfully integrating AOP into your project.
Aspect
Advice
Joinpoint
Pointcut
We have learned what aspect (Aspect) is! Now let us understand what the other three conditions mean?
Advice (notification)
Advice is used to call Aspect (aspect). As its name implies, Advice is used to define what to do in a certain situation and when to do it. . In our previous example, checkAuthentication (what to do) is advice (notification), in the specified method it should be called before (when) the code is executed.
Joinpoint
Joinpoint is the location where we create the Advice application. Looking at the previous code again, you will find that I called several functions that are not directly related to business logic. In createPost(), for example, cross-cutting concerns should occur before executing the validation logic and after sending the message to the administrator. These may all be access points.
Access points can be placed anywhere in your application code. But Advice can only be deployed at certain points, depending on your AOP framework, which I will discuss later.
Pointcut
Pointcut defines a way to match notifications to certain access points. Although there is only a pair of access points in our example, you can have thousands of access points in your application, and you do not need to apply notifications to all access points. You can bind as many access points as you deem necessary to notifications.
Suppose we want to notify createPost(), approvePost() and editPost(), but there is no viewPost(). We use some method to bind these three methods to the notification. We then create an XML file containing the aspect details, which contain some regular expressions that match the access points.
Summary: When there is a horizontal cutting relationship in our application, we can create an aspect that applies the notification function on some access points that choose to use point cutting.
AOP notification type
We can express the notification code in many ways. I mentioned before that these notification codes depend on the framework you are using, but there are some types you need to be familiar with, see below:
Pre-Notification
Post-Return Notification
Post-Throw Notification
Peripheral Notification
Pre-notifications
Use notifications before some special point in your code - normally calling a method.
So far, in order to simplify the concept and allow you to understand your code faster, I have always written notifications into methods. But in real environments, notifications are often not written in methods. There should be an independent controller, each method is in this controller, and each method wraps AOP functionality. This global controller runs throughout the system and is invisible to us.
class PathController
{
function controlPaths ($className, $funcName) {
Authentication::checkAuthentication();
$classObj = new $className();
$classObj->$funcName();
}
}
Assume there is such a class here, mainly to show you what actually happens in this class. Assume that the controlPaths method is the global entry point in the application, and every method in the application needs to be accessed through this method. In the above method, before executing each method, we call the notification checkAuthentication(). ——This is the pre-notification.
Notification after return
This notification is only executed once after the specified function is executed, and returns to that access point. Consider the following code:
class PathController
{
function controlPaths($className, $funcName) {
$classObj = new $className();
$classObj->$funcName();
Database::closeConnection();
}
}
Press Ctrl+C to copy the code. Note here that after the method is completed, we clean up the database resources. After returning the notification, we call this notification.
Post-throw notification
If the function throws an exception during the execution of the process, the notification is applied after the exception is thrown. Here, after the exception is thrown, the notification becomes an error message.
class PathController
{
function controlPaths ($className, $funcName) {
try {
$classObj = new $className();
$classObj->$funcName();
}
catch (Exception $ e ) {
Error::reportError();
Peripheral notification
The fourth kind of notification is peripheral notification, which is a combination of pre-notification and post-return notification.
Copy code
The code is as follows:
Logger::endLog ();
}
}
http://www.bkjia.com/PHPjc/326806.html