Interpreting AOP again

As mentioned above, the thinking of SOA may be somewhat divergent. However, it is absolutely beneficial for me to stick to the Service Oriented design idea of such a higher abstraction level. Of course, this is to be tested in practice. On the other hand, I am planning a SOAHelper open-source framework that will provide some convenience for development based on the general SOA idea. Of course, the SOA mentioned here is not a strict standard definition of SOA in the industry. But a higher level of abstraction. However, for strict SOA, it is also beneficial. No, it should be the main service object. This is the end point. I 'd like to mention it here. Back to the topic, this article re-interprets SOA & AOP, that is, re-interpreting AOP. You can rest assured that this article will not be as divergent as SOA, so that everything is AOP. After all, AOP is an extension of abstract ideas based on OO, the topic here is the significance of AOP and the implementation of AOP is the future development trend of AOP, in particular, we will describe a so-called container-Type Binary/IL-level AOP-based interception mechanism. - What is AOP?Here, we will reference the definition and explanation in wayfarer's article "third only looking at AOP". (If you are interested, you can refer to my reference. an article series of AOP under. Net): Simply put, AOP refers to the logic or responsibility that has nothing to do with the business but is called by the business module, for example, transaction processing, log management, and permission control are encapsulated to reduce repeated system code, reduce coupling between modules, and facilitate future operability and maintainability. Essentially, AOP is only a supplement or improvement of OOP. It transforms the paradigm and perspective of programming and focuses on the corners that have been ignored or cannot be solved by OOP for a long time, this allows developers to better separate their responsibilities (such as banking and transaction processing. Through Aspect-oriented programming, the program's responsibilities can be separated, and objects and aspects do not interfere with each other. The Aspect-Oriented module does not explicitly call an object. Instead, it obtains messages between methods in the encapsulated object through or injection or intercept, and then processes the messages accordingly. Maybe the aspect-oriented model breaks down the encapsulation of objects, but just like this can reduce the coupling between modules. Similarly, by encapsulating "aspect", these general functions are separated from different classes so that different modules can share the same "aspect ", this greatly reduces repeated code. -The above is a general understanding of AOP. Of course, this is true. In essence, this is the case of AOP. However, I believe that after reading the above explanation, I will still find out when to use AOP. Why should I use AOP instead of the traditional OO design idea to implement my software functions? Once I think that AOP sounds good, I have tried it, and may have more questions and concerns about performance, debugging, transaction consistency, and so on. If you feel these worries, you are very rational. There will be such concerns. On the one hand, the implementation of AOP is not as intuitive as OO, and the implementation of AOP tools is not as convenient as OO; on the other hand, in fact, most people are confused about the time to use AOP, that is, how to deal with the incidental problems that may arise from the application of AOP. I don't expect you to eliminate this problem after reading this article, but I will try my best to ease this feeling. -Speaking of AOP, I would like to mention MDA. I have not verified which of the two words was first proposed. However, I suspect it is MDA. What is the relationship between AOP and MDA? Let's first talk about the basic idea of MDA. MDA, Model Driven Architecture, is a Model-Driven software Architecture. The inventor hopes that future software development can use a Model, a more intuitive Graphic Language (generally, the model here refers to UML), and designs software systems like building blocks. Ideally, once the model is fully defined, from platform-independent models (PIM) to platform-related models (MSPs ), the final executable program code process is as automated as possible. -Of course, this is the idea of MDA at the beginning. With the in-depth research, people have found many less practical problems. The first is that the PIM layer is often too complex and difficult to be componentized. we can imagine that, even for a relatively similar domain like workflow, even for the same system, users often have different requirements for security, logs, and transactions. However, many systems are similar to the core workflow engine. At this point, some people have discovered AOP. Imagine using the idea of AOP to separate the logic with higher possibility of some changes. First, focus on the refinement and reuse of the core business logic, is PIM clearer? As a result, it was proposed that the process of MDA could be modified into a new model: At first, apart from the model (PIM) unrelated to the core basically unchanged platform, a new set of Aspect (Aspect) layers were added, for example, log, security, transaction, Qos, and other cross-section models (Aspects). Step 2, integrate PIM and Aspects under certain context conditions through certain Converter, it becomes a platform-independent integration model (EPIM), which is called an improved platform-independent integration model (EPIM). Finally, the EPIM is converted to the PSM. What are the benefits of doing so? The main advantage is that some of the core services of the system are basically unchanged, such as workflows and CRM, but there are a lot of uncertain and changeable, sometimes, if you need something that is not needed at the time, you can make the core business components as sufficient as possible, and make the easy-to-change Aspects into Aspects, which makes the messy PIM, a little clearer. It seems that AOP seems to be useful. But is that enough? -Can I only reuse the same business model as a whole, but cannot be further subdivided? If one component flow shows more beautiful, but the other component has better performance, can I select either of them? Where is the key? The key is that the components are not detailed enough. However, unfortunately, this is not detailed enough. We don't want to score, but we can't do anything about it. Why is it powerless? What are the bottlenecks? Sorry, It Is OO. The bottleneck of the problem lies in OO. Why? This is what I mentioned in my previous article on SOA: the author of smalltalk makes us think that everything in the world is an object, and all objects can be inherited through interfaces, by reloading and so on, these OO elements can be fully described. This is actually ridiculous! Not to mention, there is no process in the world. After all, I can make an object contain only the process and use its name to encapsulate the process. What is the biggest difference between objects in OO and objects in the real world? The biggest difference is that objects in the real world, such as people, must be clear in a specific context. For example, when a person works in an organizational unit, he is an Employee. when he is in the gym, he is a physical exercise user. When he is with his wife, it is a husband. The attributes and methods of each role are different. So what attributes should a person have? With OO, he can only describe with inheritance. OK, the Employee inherits from the simplest person, the gym user can also inherit from the person, and the husband can also inherit from the person, then I will ask you, how do you express this person if he and his wife are talking and smiling in the gym?  Have you found any problems? Repeat, an object is clear only in a specific context. When the context is different, its attribute methods may be completely different.When a programmer writes code in front of a computer, who cares about his wife? When the boss cares about the quality of the Code he writes, how much fat does the boss care about from time to time? Yes, I want to explain that pure OO does not describe the natural method of this very common scenario. -Let's imagine how to solve this problem. Obviously, we need to solve the problem that when a person is in a specific context, they naturally have these additional attributes and methods, and when this person is in a centralized environment, naturally, there is a problem of overlapping additional attributes and methods. The most intuitive way to solve such a problem is to use a container to represent a context environment, and the Environment is variable. When the environment changes, the human factors in the environment change, the Administrator should automatically obtain additional attributes and methods.Is there any technology that can achieve this effect? Yes, it's exactly the theme we're talking about. AOP! According to this idea, some people have proposed such an idea to further expand the above second improved MDA process: the components are subdivided into finer particles, such as individual components, different from Aspects that describe the additional attributes and methods of people in different contexts. In this way, both PIM and Aspect in the previous model are carried by a container. When every container contains people or even a general transaction processing component, as long as a special Aspect component with different descriptions of additional attributes is inserted, this container describes a combination that better meets the context requirements. Assume that the mixture we call is MPIM and MAspect, then the following will not change, and the EMPIM and EMAspect will be generated accordingly, and finally converted to the Code for executing the command and executing the command. In this way, do you think the implementation of MDA is more practical? - Of course, although the above analysis focuses on the improvement of the process of MDA, even if the current application of MDA is not widely used, I personally think that, it is also the future development direction of componentization. Fine-grained components, combined with the AOP hybrid of container management, can reuse software components to a very high level.I think, through the above discussion, how much should you agree? If we talk about the specific AOP implementation method, there are generally two options, which are also the two main lines of the current AOP framework, namely, DynamicProxy and StaticWeave (there are also some optional solutions, such as in. net2.0 allows dynamic append of a dynamic method for a class, so we will not comment on its limitations here ), For these two implementation lines, I tend to, or I am more certain about them. I am only optimistic about StaticWeave. Why? Imagine that a person in a certain context in a later software system is a mix of hundreds or even thousands of overlapping contexts. If DynamicProxy is used for implementation, what is the efficiency?In the short term, the DynamicProxy-based AOP tool like Castle and Aspect # can also achieve certain results. However, in the long term, I think, the automated design of componentized Software Based on the static weaving idea of container management must be the future development direction. Such a general container that is easy to statically woven is also the direction I hope to achieve. I don't dare to judge the specific effect, but I believe that although I don't believe it, it can play a very good effect. Still need to be tested in practice ~~