領先一步
VMware 提供培訓和認證，以加速您的進步。
瞭解更多事務、快取和 AOP：理解 Spring 中的代理使用
在 Spring 框架中，許多技術特性都依賴於代理的使用。我們將使用三個示例深入探討這個主題：事務、快取和 Java 配置。
本部落格文章中顯示的所有程式碼示例都可以在我的 github 帳戶上找到。
事務
第一步：無事務
下面的 Service 類尚未事務化。 讓我們首先看看它原本的樣子，然後再使其成為事務性的。
@Service
public class AccountServiceImpl implements AccountService {
//…
//Not specifying a transaction policy here!
public void create(Account account) {
entityManager.persist(account);
}
}
由於方法“create”不是事務性的，因此很可能會丟擲異常（因為不應在事務之外持久化此 Account 物件）。
這是我們在執行時擁有的：
第二步：新增事務行為配置
現在讓我們在 create(…) 方法之上新增 @Transactional
@Service
public class AccountServiceImpl implements AccountService {
@PersistenceContext
private EntityManager entityManager;
@Transactional
public void create(Account account) {
entityManager.persist(account);
}
}
這是相應的 Spring 配置
<bean id="transactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>
<tx:annotation-driven/>
在 Spring 的通用配置中，我們使用了 <tx:annotation-driven />。 這意味著所有 @Transactional 註解都應在啟動時掃描，並且目標方法應變為事務性的。 那麼事務行為在哪裡發生呢？
在啟動之前，我們仍然擁有與之前相同的檔案
在啟動時，會建立一個新類，稱為代理。 此類負責新增事務行為，如下所示
生成的代理類位於 AccountServiceImpl 之上。 它向其新增事務行為 [1]。
那麼如何確保確實正在使用代理？ 為了您自己的理解，回到程式碼中並親眼看到您確實在使用代理非常有趣。
一種簡單的方法是打印出類名
AccountService accountService = (AccountService) applicationContext.getBean(AccountService.class);
String accountServiceClassName = accountService.getClass().getName();
logger.info(accountServiceClassName);
在我的計算機上，它顯示以下輸出
INFO : transaction.TransactionProxyTest - $Proxy13
此類是動態代理，由 Spring 使用 JDK 反射 API 生成（更多資訊請參見 此處）。
在關閉時（例如，當應用程式停止時），代理類將被銷燬，並且您將僅在檔案系統上擁有 AccountService 和 AccountServiceImpl
Spring 如何代替目標類來連線代理？
讓我們考慮一個使用 AccountService 例項的類
```java
注意：Spring 3.1 嵌入了一個相當簡單的快取實現。 通常建議使用另一個實現，例如 ehcache。 在此處提供的示例應用程式 (https://github.com/michaelisvy/proxy-samples) 中，您將找到一些使用嵌入式快取實現和 ehcache 的示例。
@Controller public class AccountController { private AccountService accountService;
private void setAccountService(AccountService accountService) { this.accountService=accountService; }
//… }
<a href="http://blog.springsource.org/wp-content/uploads/2012/05/proxy-and-target1.png"><img class="aligncenter size-full wp-image-11128" title="proxy-and-target" src="http://blog.springsource.org/wp-content/uploads/2012/05/proxy-and-target1.png" alt="" width="316" height="255" /></a>
</div>
<div>
The attribute accountService is of type AccountService (interface). The variable dependency is on the interface type AccountService, not the implementation type, which reduces the coupling between classes. This is a best practice.
As seen before, both AccountServiceImpl and the generated Proxy implement the interface AccountService.
• If there is a proxy, Spring injects the proxy
• If not, Spring injects the instance of type AccountServiceImpl.
</div>
<h3><a name="cache">Caching</a></h3>
<div>
Declarative caching is a new feature in Spring 3.1 that works like Spring’s declarative transaction support.
The @Cacheable annotation should be used in that way:
</div>
<div>
```java
public class AccountServiceImpl implements AccountService {
@Cacheable(value="accounts", key="#id")
public Account findAccount (long id) {
// only enter method body if result is not in the cache already
}
}
您還應該在 Spring 配置中啟用快取，如下所示
<cache:annotation-driven />
這是預期的結果
accountService.findAccount (1); // Result stored into cache for key “1”
accountService.findAccount (1); // Result retrieved from cache. Target method not called.
accountService.findAccount (2); // Result stored into cache for key “2”
在執行時，代理用於新增快取行為。
注意：Spring 3.1 嵌入了一個相當簡單的快取實現。 通常建議使用另一個實現，例如 ehcache。 在此處提供的示例應用程式 (https://github.com/michaelisvy/proxy-samples) 中，您將找到一些使用嵌入式快取實現和 ehcache 的示例。如果 bean 類未實現任何介面怎麼辦？
在前面的示例中，我們提到代理應實現與您的 bean 相同的介面。 值得慶幸的是，Spring 還可以代理沒有介面的 bean。 在許多情況下，實現介面不是最好的方法。預設情況下，如果您的 bean 未實現介面，Spring 將使用技術繼承：在啟動時，將建立一個新類。 它從您的 bean 類繼承並在子方法中新增行為。
為了生成此類代理，Spring 使用一個名為 cglib 的第三方庫。 不幸的是，此專案不再活躍。 在 Spring 3.2 中，Spring 很可能會預設使用 Javassist（請在此處檢視更多詳細資訊）。
Java 配置
注意：本節需要一些 Spring 中 Java 配置的背景知識。 如果您不熟悉這種新的配置樣式，請隨時跳過它。
使用 Java 配置時，配置儲存在 Java 類中，例如此類
```java
@Configuration public class JavaConfig {
@Bean public AccountService accountService() {
return new AccountServiceImpl((accountRepository()); } @Bean public AccountRepository accountRepository () { //… }
}
Spring calls the method accountService() every time it needs to wire an instance of the bean “accountService” and this one returns a “new” object of type AccountService. If 10 beans are using a dependency of type AccountService, this method is called 10 times.
However, no matters the Spring configuration has been made using Java Configuration or not, every bean should be a singleton by default. How is that possible and where is the magic happening?
This diagram explains how things work internally:
</div>
<div><a href="http://blog.springsource.org/wp-content/uploads/2012/05/java-config.png"><img class="aligncenter size-full wp-image-11131" title="java-config" src="http://blog.springsource.org/wp-content/uploads/2012/05/java-config.png" alt="" width="507" height="328" /></a></div>
<div>
So the Proxy is adding behavior there. In the case that your bean should be a singleton, the action to turn your Plain Old Java Object into a singleton is performed by a child class (Proxy).
</div>
<div>
<h3>Conclusion</h3>
We’ve seen some use-cases on how proxies are used inside the Spring framework. There are many other examples: Aspect Oriented Programming, Security (using Spring Security), thread safety, scopes, etc…
If you would like to know more on the impact on performance when using proxies, you can read <a href="http://blog.springsource.org/2007/07/19/debunking-myths-proxies-impact-performance/">Alef Arendsen’s blog entry here</a>.
</div>
<div>
<hr size="1" />
<div><a name="note">[1]</a>to be exact: the proxy class does not contain the transaction code internally. It delegates transaction handling to some classes that are part of the Spring framework. Spring will then handle transactions according to the Transaction Manager you have declared.
</div>
</div>