Preface

A few years ago I was working on a team of consultants embedded in an organization (that shall remain unnamed). Our job was to create a system that would help increase a key source of revenue. This organization’s IT department had many problems: political, technical, organizational, and financial. As consultants, we, naturally, wanted to overhaul everything immediately to solve these problems, but the reality of consulting is that we had to take very slow, very small steps toward the goal. In the meantime, we had to work around the technical and organizational problems in order to help solve the financial ones, and that’s how I first learned about aspect-oriented programming (AOP).

We were creating a website for the public to submit registration information and pay fees. One of the constraints we faced when writing this system was the enterprise database. We had to access the enterprise data via an unreliable and error-prone service that was meant to act as this organization’s SOA (service-oriented architecture). There were some good ideas in this service, but the implementation was poor: sometimes as many as half the requests to this system would result in an exception, seemingly at random. After considerable testing and tinkering, we discovered that simply retrying the identical request once or twice would result in a successful request. Because of this, we didn’t want to use this buggy, unproven SOA service, but at that point we didn’t have a choice.

We needed to create a reliable website that would be able to function with an unreliable layer of data persistence and enterprise services. What we built was a piece of code that would begin a transaction, try a request, catch exceptions of a certain type, and retry the request until it succeeded, or roll it back if it didn’t. If it didn’t succeed, it would log the exception type, the exception message, and some related information about the request. With this log, we hoped to first, build evidence that we could use to prove how unreliable this SOA service was, and second, be able to match exceptions with any customer-reported technical issues. What we built was a critical transaction helper class that was used over and over every time we needed to use the SOA service.

This leads me to one of the organizational problems: the QA department was responsible for testing our application, but QA was notorious for being overworked and/or unreliable. This meant that they might not get around to reporting a bug that they found in our project until possibly two weeks later, or more. If one of us on the team accidentally forgot to use our transaction helper class when accessing the SOA service (or when someone new to the team was unaware of this helper class), then we might not find out for weeks, even if QA was (un)lucky enough to get one of the random exceptions.

I was pulling my hair out: surely there was a way to refactor this nonfunctional requirement so we didn’t have to worry about forgetting it. Plus, it was getting tangled up with the rest of our code, making it harder to read and maintain.

By chance, I was attending a .NET conference in Ohio, and Michael Kramer, an acquaintance of mine, was giving an introductory talk on AOP using PostSharp. He showed basic 101-level examples, similar to the ones you’ll see early in this book. The idea of being able to write a piece of code that would be in class A yet run somewhere else (say, before and after the methods in class B) was astounding to me, and I mentally checked out of the rest of the conference and immediately started thinking of ways to apply AOP to the transaction helper class problem.

Fast-forward to now, and I’m still using AOP to solve similar problems (although I left that organization and the consulting business altogether). I started speaking at software conferences about AOP, started blogging about AOP, and became something of a community advocate for AOP. I was often asked if I could recommend a book on the topic for .NET developers, and I really couldn’t. I eventually decided that this book had to be written. So that’s what you have here, a book on a topic about which I am very passionate—not only because it’s a powerful and useful tool when used properly, but because it helped me out in a very tough situation.