Infra AOP Capabilities and Goals
Infra AOP is implemented in pure Java. There is no need for a special compilation process. Infra AOP does not need to control the class loader hierarchy and is thus suitable for use in a mockApi container or application server.
Infra AOP currently supports only method execution join points (advising the execution of methods on Infra beans). Field interception is not implemented, although support for field interception could be added without breaking the core Infra AOP APIs. If you need to advise field access and update join points, consider a language such as AspectJ.
Infra AOP’s approach to AOP differs from that of most other AOP frameworks. The aim is not to provide the most complete AOP implementation (although Infra AOP is quite capable). Rather, the aim is to provide a close integration between AOP implementation and Infra IoC, to help solve common problems in enterprise applications.
Thus, for example, the TODAY Framework’s AOP functionality is normally used in conjunction with the Infra IoC container. Aspects are configured by using normal bean definition syntax (although this allows powerful "auto-proxying" capabilities). This is a crucial difference from other AOP implementations. You cannot do some things easily or efficiently with Infra AOP, such as advise very fine-grained objects (typically, domain objects). AspectJ is the best choice in such cases. However, our experience is that Infra AOP provides an excellent solution to most problems in enterprise Java applications that are amenable to AOP.
Infra AOP never strives to compete with AspectJ to provide a comprehensive AOP solution. We believe that both proxy-based frameworks such as Infra AOP and full-blown frameworks such as AspectJ are valuable and that they are complementary, rather than in competition. Infra seamlessly integrates Infra AOP and IoC with AspectJ, to enable all uses of AOP within a consistent Infra-based application architecture. This integration does not affect the Infra AOP API or the AOP Alliance API. Infra AOP remains backward-compatible. See the following chapter for a discussion of the Infra AOP APIs.
|
One of the central tenets of the TODAY Framework is that of non-invasiveness. This is the idea that you should not be forced to introduce framework-specific classes and interfaces into your business or domain model. However, in some places, the TODAY Framework does give you the option to introduce TODAY Framework-specific dependencies into your codebase. The rationale in giving you such options is because, in certain scenarios, it might be just plain easier to read or code some specific piece of functionality in such a way. However, the TODAY Framework (almost) always offers you the choice: You have the freedom to make an informed decision as to which option best suits your particular use case or scenario. One such choice that is relevant to this chapter is that of which AOP framework (and which AOP style) to choose. You have the choice of AspectJ, Infra AOP, or both. You also have the choice of either the @AspectJ annotation-style approach or the Infra XML configuration-style approach. The fact that this chapter chooses to introduce the @AspectJ-style approach first should not be taken as an indication that the Infra team favors the @AspectJ annotation-style approach over the Infra XML configuration-style. See Choosing which AOP Declaration Style to Use for a more complete discussion of the advantages and disadvantages of each style. |