前言

我們先探一探官方文檔關(guān)于Method Injection的章節(jié)是怎么說的：

In most application scenarios, most beans in the container are singletons. When a singleton bean needs to collaborate with another singleton bean or a non-singleton bean needs to collaborate with another non-singleton bean, you typically handle the dependency by defining one bean as a property of the other. A problem arises when the bean lifecycles are different. Suppose singleton bean A needs to use non-singleton (prototype) bean B, perhaps on each method invocation on A. The container creates the singleton bean A only once, and thus only gets one opportunity to set the properties. The container cannot provide bean A with a new instance of bean B every time one is needed.

用一句話概括就是 一個(gè)單例Bean A每次獲取另外一個(gè)Bean B的時(shí)候怎么保證這個(gè)Bean B是一個(gè)新的實(shí)例?

正文

ApplicationContextAware接口

官方文檔首先也提到了一個(gè)解決方案就是把A弄成容器的Aware( make bean A aware of the container),也就是實(shí)現(xiàn)ApplicationContextAware接口。

A solution is to forego some inversion of control. You can make bean A aware of the container by implementing the ApplicationContextAware interface, and by making a getBean("B") call to the container ask for (a typically new) bean B instance every time bean A needs it. The following example shows this approach

文檔里隨后就提供了一個(gè)示例來說明這個(gè)解決方案如何做。

// a class that uses a stateful Command-style class to perform some processing
package fiona.apple;
// Spring-API imports
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

public class CommandManager implements ApplicationContextAware {
 private ApplicationContext applicationContext;
 public Object process(Map commandState) {
  // grab a new instance of the appropriate Command
  Command command = createCommand();
  // set the state on the (hopefully brand new) Command instance
  command.setState(commandState);
  return command.execute();
 }
 protected Command createCommand() {
  // notice the Spring API dependency!
  return this.applicationContext.getBean("command", Command.class);
 }
  public void setApplicationContext(
   ApplicationContext applicationContext) throws BeansException {
  this.applicationContext = applicationContext;
 }
 }

雖然解決了一開始提出的問題，但是Spring隨后就說到：

The preceding is not desirable, because the business code is aware of and coupled to the Spring Framework. Method Injection, a somewhat advanced feature of the Spring IoC container, lets you handle this use case cleanly.

也就是說 前面的方法是不可取的，因?yàn)闃I(yè)務(wù)代碼知道并耦合到Spring框架。那怎么降低這個(gè)耦合度呢？后半句就給出了答案：方法注入是Spring IOC容器的一個(gè)稍微高級(jí)的特性，它允許您干凈地處理這個(gè)用例。

Lookup Method方法注入

首先再次引入官方文檔中的闡述：

Lookup method injection is the ability of the container to override methods on container-managed beans and return the lookup result for another named bean in the container. The lookup typically involves a prototype bean, as in the scenario described in the preceding section. The Spring Framework implements this method injection by using bytecode generation from the CGLIB library to dynamically generate a subclass that overrides the method.

簡要概括下這段話有三個(gè)意思：

• Lookup Method注入可以讓容器重寫容器中bean上的方法并返回容器中另一個(gè)bean的查找結(jié)果。
• Lookup通常會(huì)是一個(gè)原型bean，如文章開頭所說的。
• Spring框架通過使用CGLIB庫中的字節(jié)碼生成來動(dòng)態(tài)生成覆蓋該方法的子類，從而實(shí)現(xiàn)這種方法注入。

使用Lookup方式需要注意以下幾點(diǎn)：

• For this dynamic subclassing to work, the class that the Spring bean container subclasses cannot be final, and the method to be overridden cannot be final, either.
• Unit-testing a class that has an abstract method requires you to subclass the class yourself and to supply a stub implementation of the abstract method.
• Concrete methods are also necessary for component scanning, which requires concrete classes to pick up.
• A further key limitation is that lookup methods do not work with factory methods and in particular not with @Bean methods in configuration classes, since, in that case, the container is not in charge of creating the instance and therefore cannot create a runtime-generated subclass on the fly.

這段話也可以概括為以下幾點(diǎn)：

1. 使這個(gè)動(dòng)態(tài)子類可以用，這個(gè)類不能是final，要重寫的方法也不能是final。
2. 單元測試具有抽象方法的類需要您自己對(duì)該類進(jìn)行子類化，并提供抽象方法的存根實(shí)現(xiàn)。
3. 具體的方法對(duì)于組件掃描也是必要的，這需要具體的類來獲取。
4. 一個(gè)關(guān)鍵限制是Lookup方法不適用于工廠方法，尤其是配置類中的@Bean方法，因?yàn)樵谶@種情況下，容器不負(fù)責(zé)創(chuàng)建實(shí)例，因此不能動(dòng)態(tài)創(chuàng)建運(yùn)行時(shí)生成的子類。

接下來Spring就拿上面本來基于ApplicationContextAware的方法來說，就可以用Lookup來替換了。對(duì)于前面代碼段中的CommandManager類，Spring容器動(dòng)態(tài)重寫createCommand()方法的實(shí)現(xiàn)。CommandManager類沒有任何Spring依賴項(xiàng)，如修改后的示例所示

In the case of the CommandManager class in the previous code snippet, the Spring container dynamically overrides the implementation of the createCommand() method. The CommandManager class does not have any Spring dependencies, as the reworked example shows.

Xml配置lookup-method

 public abstract class CommandManager { 
  public Object process(Object commandState) {
   // grab a new instance of the appropriate Command interface
   Command command = createCommand();
   // set the state on the (hopefully brand new) Command instance
   command.setState(commandState);
   return command.execute();

 }
 // okay... but where is the implementation of this method?
  protected abstract Command createCommand();
 }

在包含要注入的方法的CommandManager類中，要注入的方法需要以下形式的簽名:

<public|protected> [abstract] <return-type> theMethodName(no-arguments);

如果方法是抽象的，則動(dòng)態(tài)生成的子類將實(shí)現(xiàn)該方法。否則，動(dòng)態(tài)生成的子類將重寫在原始類中定義的具體方法。

我們來看下Bean的配置：

當(dāng)需要myCommand這個(gè)Bean的新實(shí)例時(shí)，被標(biāo)識(shí)為commandManager的bean就會(huì)調(diào)用自己的createCommand()方法。如果需要的話，必須小心地將myCommand 這個(gè)bean部署為原型。如果是單例，則每次都返回相同的myCommand bean實(shí)例.

@Lookup注解

在基于注解的組件模型中，可以通過@lookup注釋聲明查找方法，如下例所示

 public abstract class CommandManager {
  public Object process(Object commandState) {
   Command command = createCommand();
   command.setState(commandState);
   return command.execute();
  }
  @Lookup("myCommand")
  protected abstract Command createCommand();
 }

或者，你也可以依靠目標(biāo)bean根據(jù)lookup方法的聲明返回類型進(jìn)行解析

public abstract class CommandManager {
  public Object process(Object commandState) {
   MyCommand command = createCommand();
   command.setState(commandState);
   return command.execute();
  }
  @Lookup
  protected abstract MyCommand createCommand();
 }

需要注意的是你通常應(yīng)該用一個(gè)具體的存根實(shí)現(xiàn)聲明這種帶注解的查找方法，以便它們與Spring的組件掃描規(guī)則兼容，默認(rèn)情況下抽象類會(huì)被忽略。此限制不適用于顯式注冊(cè)或顯式導(dǎo)入的bean類。也就是說如果用組件掃描Bean的話因?yàn)槌橄箢惸J(rèn)是被忽略的，但是你加上這個(gè)Lookup注解后就不會(huì)唄忽略。

Spring在最后也提供了其他兩種解決思路：

Another way of accessing differently scoped target beans is an ObjectFactory/ Provider injection point. See Scoped Beans as Dependencies。You may also find the ServiceLocatorFactoryBean (in the org.springframework.beans.factory.config package) to be useful.

1. 通過ObjectFactory或者ObjectProvider.
2. 通過ServiceLocatorFactoryBean.

這兩個(gè)方案我們之后會(huì)單獨(dú)寫文章來探討，下篇文章我打算來具體的使用下這個(gè)Lookup 方法注入并且從源碼角度來看下Spring如何巧妙地實(shí)現(xiàn)它的。

總結(jié)

到此這篇關(guān)于Spring中為何要引入Lookup注解的文章就介紹到這了,更多相關(guān)Spring為何引入Lookup內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論