During the interview, interviewers are often asked about the scenarios that AOP uses in your projects. My general answer is logs, permissions, transaction processing, method statistics, and performance monitoring. In fact, permissions and affairs are related to business, let's think about how to design for the others. The focus is on the idea of design. Source code: https://github.com/limingios/netFuture/tree/master/tuling-enhance-plugin-master
What can AOP do?
- Log
- New log
It is necessary to print.
- New log
- Query log
For the system, it is basically written less and read more. Is it necessary to record all logs? Do you print a lot of useless logs? In fact, looking at the logs is to see if there are any problems with the passed parameters, that is to say, you can only look at the logs when there are problems. Can you understand this way? Useless, the scenario I'm talking about, in fact, if it is log analysis work, maybe all the logs are necessary, but there may be some logs that do not need to be buried, there is no need to bury them, right? That is, the log is a specific log that needs to be printed, according to the business.
Disadvantages of traditional AOP
-
Not flexible enough
Generally, they are general-purpose functions, and no one does customization. If you want to print those, just print those. The code is dead, if you need to change it, you must restart the system to complete.
-
Intrusion into business
The code is written in the business function, and it is released and upgraded according to the business function. Written in the business function. Coupled in.
- Difficulty in publishing
To target an increase, you need to write code, release and upgrade the business. It's very troublesome. If a system is changed, it will be changed. If there are hundreds of businesses, they all need to be increased. high cost. too heavy. Performance monitoring may need to be written, 10 projects written 10 times.
Solution
-
Can intervene in non-business functions at low cost
Compared with the traditional writing AOP, the cost is lower, and plug-ins can be loaded remotely. Projects that do not restart. We designed one table at a time in the previous way, and there are many parameters in the table. In fact, we need to read the database every time we use the business method. Because it is very slow, we changed to redis, but after changing the value, we need to delete the redis Content. This method is not the best. Without restarting, flexibility is guaranteed.
- Very flexible
Dynamically update plug-ins, enable and stop plug-ins. Automatically download the plug-in, even if the application is restarted, there is a local cache to save the previous settings.
Source structure diagram
PS: I won't say much in detail, just look at the source code, and mainly understand that there is classload to load the corresponding class in this idea, and get Advice and control it through the spring IOC loading bean.