Matthew D. Groves - AOP in .NET: Practical Aspect-Oriented Programming

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact

2013 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.

Recognizing the importance of preserving what has been written, it is Mannings policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine.

Manning Publications Co.20 Baldwin RoadPO Box 261Shelter Island, NY 11964

Development editors: Frank Pohlmann, Cynthia KaneTechnical proofreader: Javier LozanoCopyeditor: Nancy KotaryProofreader: Elizabeth MartinTypesetter: Dottie MarsicoCover designer: Marija Tudor

ISBN 9781617291142

Printed in the United States of America

1 2 3 4 5 6 7 8 9 10 MAL 18 17 16 15 14 13

To my children Matthew and Emma

I will never grow tired of your yelling, Daddy, Daddy! and tackling me when you hear the creak of my office door.

Like many great advances in our industry, the explicit concept of aspect-oriented programming (AOP) was developed at what is now known as PARC, a Xerox Company. Soon after, in 2001, the AspectJ extensions brought AOP to Java. Aspects have enjoyed a long history in the Java community, but for many .NET developers, aspects are still considered new and exotic. Even so, many .NET developers have been using them without knowing it.

Aspects provide a means of separating cross-cutting concerns from your core implementation code into separate modules. Rather than having every method contain logging code, for example, a logging aspect can be applied to methods external to the method implementation. Its a powerful technique to help employ the principle of separation of concerns within code.

In AOP in .NET, Matthew D. Groves deftly shines a light on the many ways developers can take advantage of aspects in .NET. He begins with an approachable introduction to AOP and builds on that with an example of an application written without aspects, which is then cleaned up with aspects. Subsequent chapters dig deeper into the various types of aspects and how to apply them using PostSharp and Castle DynamicProxy.

Each chapter builds on the previous one in a distinct, understandable style, each with sample code that clarifies the concepts covered in the chapter. Great care was obviously put into the code samples.

One example in particular shows how aspects are not limited to intermediate language (IL) rewriting and method interception. He challenges this implicit assumption by showing an aspect that wraps an HTTP request boundary in ASP.NET through a custom HttpModule implementation. Its an example that might not, at first glance, be thought of as an aspect. But on reflection, it obviously meets the definition. Aspects are not limited to compile-time interception. This drives home the point that many developers have been using aspects of one form or another for a long time without realizing it.

One subject near and dear to me is unit testing and this book contains an entire chapter covering the implications of unit testing and how to unit test aspects. Its clear this book is not just meant to educate the reader on a subject, but to help the reader integrate the techniques and technologies with real-world practices.

AOP in .NET is a great resource for those interested in learning how aspects can help maintain separation of concerns in a code base. I encourage you to take a look.

P HIL H AACK

D EVELOPER , G IT H UB

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 organizations 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 thats 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 organizations 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 didnt want to use this buggy, unproven SOA service, but at that point we didnt 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 didnt. If it didnt 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.