The main benefit of aspect-oriented programming is that it complements object-oriented programming. Object-oriented programming has spread into a very, very successful paradigm, and one of the great things about it is the way in which it helps you foster reuse and remove duplication. So, for example, if you have an account class and you [extend] from that savings account, checking account and credit account, you have a very nice way of using that hierarchy to encapsulate logic that you want to reuse.
Where it does, fall down, however, [is] in addressing what we call crosscutting concerns. Crosscutting concerns are pieces of functionality that may apply to a whole system that would, if they're implemented in the traditional object-oriented way, affect multiple classes and methods. Let's take, as an example, the notion of auditing. There is, of course, the ability to have helper functionality in a base class, like a base account class, that will, for example, run auditing behavior. But what happens if we say that every method that can lead to a change in the state of the savings account should be audited? There is no way in classic OO-modeling to avoid duplication in doing that. You will end up with the auditing code scattered between multiple methods. And, of course, it gets much worse when you say that auditing should apply to savings accounts, that it also should apply to different areas of functionality, such as inventories and addresses. The problem of duplication becomes still worse.
So aspect-oriented programming introduces the concept of an aspect. An aspect really is a way of modularizing the code that will apply a crosscutting concern. [With] the Spring Framework, the transaction management and security are delivered by an aspect approach, so users are not necessarily forced to explicitly work with OOP constructs, but they nevertheless benefit from this modularization of code that would otherwise be scattered.
Explain your role in the development of the Spring Framework. And could you briefly compare Spring to other frameworks, such as JavaServer Faces and WebWork?
The Spring Framework grew out of my first book on J2EE, Expert One-on-One J2EE Design and Development, which was published in late 2002. That book really helped to start what we might call the lightweight revolution in J2EE. It really argued that the traditional model was way too complex, and with the book I actually published 30,000 lines of code, which was originally intended to show my view on how things could be done in a simpler way through an application framework. But, of course, many readers became very interested in this and quickly I was persuaded to make it an open-source project. So development started in earnest in early 2003. Compared to other frameworks, Spring really created a niche for itself.
So Spring is what we call an application framework, and it actually addresses multiple architectural tiers. So if you look at frameworks [such as] Struts or WebWork, they more often than not just address one architectural layer. So Struts and WebWork are both Web frameworks. Compared to JSF, Spring and JSF are not really in the same space. JSF is essentially a component model for rendering Web resources, whereas Spring is more a framework that aims to bring an overall structure and coherency to your application as a whole. So Spring actually can be used with JSF. Spring does provide its own MVC [Model-View Controller] Web framework, which I guess can be regarded as being in the same space as Struts and WebWork, but, on the other hand, Spring is a modular framework.
)
No comments:
Post a Comment