As enterprise systems evolve from concept to code, an otherwise clean design can become downright, well, messy, as the practical plumbing of logging, caching, transactions, and more infiltrates modules. Wouldn’t it be better if, say, logging were just another module? Enter aspect-oriented programming.
Consider the life cycle of a typical e-commerce project. First, you might decide to architect your code around an object-relational (OR) mapping tool, such as Java Data Objects or Hibernate, and J2EE services, such as servlets and the Java Authentication and Authorization Service. Next, you create interfaces and classes representing business concepts such as a customer, SKUs, a shopping cart, inventory, and payment authorization. At this point, your code is clean and comprehensible.
Then you encounter some inexplicable, intermittent behavior. “Of course! I need logging,” you say. So, you meticulously modify all of the methods in all of the classes to use log(). Now when a bug occurs, you examine the log and understand the sequence of activities that lead to the bug.
But before you get to pat your own back, you realize that performance isn’t up to snuff. You profile your code. “I need caching!” you exclaim. You modify many classes to introduce caching, all the while fully aware that you still need to implement a security solution, too. You implement that, but now your code is messy, and the clean outlines of your original design begin to blur.
This saga continues much the same way for error handling, transaction management, business rules, and so on. Even if you’d used a framework such as Enterprise Java Beans (EJB), the story wouldn’t be much different: the work would start off a little easier — until you have to venture beyond the boundaries of…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
