4.0 Aspect-oriented Spring （Spring 面向切面）

Aspect-oriented Spring （Spring 面向切面）
本章概述
面向切面编程基础
从POJO创建切面
使用@AspectJ注解
向AspectJ切面注入从属

当我正在写这章的时候，德克萨斯州（我的居住地）正经历着有史以来的最高气温。非常热。在这样的天气里，空调是必须的。但是，使用空调所带来的负面情况是用电，并且电是需要花钱的。我们无法避免为了凉爽和舒适而支付开支。因为每家都有一个电表，用来精确的度量每千瓦电量，并且每个月都会有人来读电表，而电力公司就能够正确的知道需要收我们多少费用了。

现在，想象一下如果没有了电表并且每人来监督我们的用电习惯。假如由我们自己来联系电力公司，并且报告他们的用电量。尽管可能有一部分人会很执着的仔细的记录他们的电灯，电视和空调的用电量。但更多的人不会。更多的人会只是估计一下他们的用电量甚至还有一些根本就不会报告用电量。毕竟记录用电量是件很麻烦的事情，并且不支付费用又是如此的诱人。

基于道德的电力审计对于客户来说可能是很好的，但是对于电力公司来说就是个坏主意了。这就是为什么我们每家都有一个电表，并且每个月都会有人来读取耗电量回报给电力公司。

软件系统的一些功能就像是我们家里的电表一样。这些功能需要在应用程序的多个地方应用，但是不需要在每个点上显式的调用。

监控电力的消耗是一个非常重要的功能，但是对于用户来说这并不是首要的。类似于整理草坪，清理地毯，打扫浴室这类事物才是用户真正关心的。从用户的角度来看，监测家里的用电量是一个被动事件。（尽管，如果整理草坪也是一件被动事件的话那是很好的——特别是在这么热的天气里）

在软件中，有一些对于应用程序来说普遍的行为。登录，安全和事务管理是很重要的，但是你的应用程序对象应该主动参与到这样的行为中来么？或者说让你的应用程序对象聚焦于业务领域问题，而其他方面由其他人来完成是不是更好？

在软件开发中，一个应用程序的功能横跨多个点被称为横切关注点。典型的，在概念上讲横切关注点是与应用程序的业务逻辑分离的（但通常是直接内嵌进入的）。将横切关注点从业务逻辑分离就是面向切面编程（AOP）所发挥的作用。

在第二章中，你了解到了如何使用依赖注入（DI）来管理和配置你的应用程序对象。DI帮助你从应用程序对象之间解耦，AOP则帮助你将横切关注点从受他们影响的对象中解耦。

登录是切面应用的一个普遍的例子。但这并不是切面唯一适用的情况。在本书中，你将会看到许多切面的实际应用，包括说明性事务，安全和缓存。

这章我们探索Spring对于切面的支持，包括如何将一个类声明为合格的切面和如何使用注解创建切面。另外，你将会看到AspectJ——另一种流行的AOP实现，可以用来补充Spring的AOP框架。但首先，在我们深入的了解事务，安全和缓存之前，切面具体实施如何在Spring中操作的。从一些AOP入门的概念开始。

This chapter covers
 Basics of aspect-oriented programming
 Creating aspects from POJOs
 Using @AspectJ annotations
 Injecting dependencies into AspectJ aspects

As I’m writing this chapter, Texas (where I reside) is going through several days of
record-high temperatures. It’s hot. In weather like this, air conditioning is a must.
But the downside of air conditioning is that it uses electricity, and electricity costs
money. There’s little we can do to avoid paying for a cool and comfortable home.
That’s because every home has a meter th at measures every kilowatt, and once a
month someone comes by to read that meter so that the electric company accu-rately knows how much to bill us.

Now imagine what would happen if the meter went away and nobody came by to
measure our electricity usage. Suppose that it were up to each homeowner to con-tact the electric company and report their electricity usage. Al though it’s possible
that some obsessive homeowne rs would keep careful record of their lights, televi-sions, and air conditioning, most wouldn’t bother. Most would estimate their usage
and others wouldn’t bother reporting it at all. It’s too much trouble to monitor
electrical usage and the tempta tion to not pay is too great.

Electricity on the honor system might be great for consumers, but it would be less
than ideal for the electric companies. That’s why we all have electric meters on our
homes and why a meter reader drops by once per month to report the consumption
to the electric company.

Some functions of software systems are like the electric meters on our homes. The
functions need to be applied at multiple po ints within the application, but it’s unde-sirable to explicitly call them at every point.

Monitoring electricity consumption is an important function, but it isn’t foremost
in most homeowners’ minds. Mowing the lawn, vacuuming the carpet, and cleaning
the bathroom are the kinds of things that homeowners are actively involved in. Moni-toring the amount of electricity used by their house is a passive event from the home-owner’s point of view. (Although it’d be gr eat if mowing the lawn were also a passive
event—especially on these hot days.)

In software, several activities are common to most applications. Logging, security,
and transaction management are important, but should they be activities that your
application objects are actively participating in? Or would it be better for your applica-tion objects to focus on the business doma in problems they’re designed for and leave
certain aspects to be handled by someone else?

In software development, func tions that span multiple po ints of an application are
called cross-cutting concerns . Typically, these cross-cutting concerns are conceptually
separate from (but often em bedded directly within) the application’s business logic.
Separating these cross-cutting concerns from the business logi c is where aspect-oriented programming ( AOP) goes to work.

In chapter 2, you learned how to use dependency injection ( DI) to manage and
configure your application objects. Whereas DI helps you decouple your application
objects from each other, AOP helps you decouple cross-cutting concerns from the
objects that they affect.

Logging is a common example of the applic ation of aspects. But it’s not the only
thing aspects are good for. Throughout this book, you’ll see several practical applica-tions of aspects, including declarativ e transactions, security, and caching.

This chapter explores Spring’s support fo r aspects, including how to declare regu-lar classes to be aspects and how to use a nnotations to create aspects. In addition,
you’ll see how AspectJ—another popular AOP implementation—can complement
Spring’s AOP framework. But first, before we get carried away with transactions, secu-rity, and caching, let’s see how aspects ar e implemented in Spring, starting with a
primer on a few of AOP’s fundamentals.