As you can see, the advice in the MessageWrapper aspect was applied to the writeMessage() method,
and the prefix and suffix values specified in the ApplicationContext configuration were used by the
advice when writing out the before and after messages.
AOP in the Sample Application
So far, you have seen lots of small examples of how to use the Spring AOP features, but as of yet, we have
not looked at some practical uses of AOP in an application. Typical examples in this field are logging and
security, and we have looked at these, albeit briefly, over the course of this chapter and the last.
However, AOP is not just limited to use in logging and security, and it can be put to great use when you
are implementing any application-specific logic that is crosscutting--that is, any logic in your
application that needs to be called from a large number of separate components. In this section, we will
give you an overview about how we use Spring AOP in the sample SpringBlog application to solve a
problem involving crosscutting logic.
Filtering Obscenities in SpringBlog
One of the problems we faced when building the SpringBlog application was how to filter obscenities
uniformly out of postings on the blog. This includes top-level blog entries as well as any comments made
about a particular entry. We needed to ensure that neither an entry nor a comment could be created
containing obscenities and that existing entries and comments could not be modified to contain
obscenities. Specifically, we wanted the ability to obfuscate obscenities contained in postings
automatically with inoffensive alternatives. Taking this further, we decided that in some cases, the blog
owner might actually want to be able to add obscenities to their entries, acting as their own moderator,
but want to restrict blog readers from posting comments containing obscenities.
The traditional approach to this problem would be to define an interface (for example, an
ObscenityFilter interface) and then build an implementation of this interface and make it accessible
through some factory class. Then, in each method where an entry or comment is created or modified,
you invoke the ObscenityFilter to remove obscenities from the posting. However, the main problem
with this approach is that all business logic that involves processing of blog entries and comments are
going to have to remember to implement this check.
Using Spring AOP, we can create a much more elegant solution to this problem by factoring the
obscenity check into a before advice that we can apply to any method that accepts a blog entry or
comment domain object as an argument. An interesting point about this implementation is that, for the
most part, we just followed good OOP practice as suggested in the traditional approach. We defined an
interface, ObscenityFilter, and then built an implementation. Thanks to Spring DI, we were able to
avoid the need to create a factory class, but by following good practices, we were able to build an
obscenity filter that can be used equally well in both AOP and non-AOP settings.
The BlogPosting Interface
Within the blog, there are two distinct types of postings: a main blog entry, represented by an Entry
object, and a comment about an entry, represented by a Comment object. Although these two objects
represent different kinds of posting, they do share similar characteristics, such as body, subject,
attachments, and date of posting. For this reason, we created an interface, BlogPosting, that allows
Comments and Entries to be manipulated at the same time. Because all the String-typed properties of
Comment and Entry are exposed on the BlogPosting interface, we use the BlogPosting interface in our
obscenity filter advice.
Search WWH :
Custom Search
Previous Page
Spring Framework 3 Topic Index
Next Page
Spring Framework 3 Bookmarks
Home