Spring: Warum verdrahten wir die Schnittstelle automatisch und nicht die implementierte Klasse?

Beispiel

interface IA
{
  public void someFunction();
}

@Resource(name="b")
class B implements IA
{
  public void someFunction()
  {
    //busy code block
  }
  public void someBfunc()
  {
     //doing b things
  }
}

@Resource(name="c")
class C implements IA
{
  public void someFunction()
  {
    //busy code block
  }
  public void someCfunc()
  {
     //doing C things
  }
}

class MyRunner
{

  @Autowire
  @Qualifier("b") 
  IA worker;

  worker.someFunction();
}

Kann mir das jemand erklären.

• Woher weiß Spring, welcher polymorphe Typ verwendet werden soll?
• Benötige ich @Qualifieroder @Resource?
• Warum verdrahten wir die Schnittstelle automatisch und nicht die implementierte Klasse?

Woher weiß Spring, welcher polymorphe Typ verwendet werden soll?

Solange es nur eine einzige Implementierung der Schnittstelle gibt und diese Implementierung mit @Componentaktiviertem Spring-Komponentenscan kommentiert ist , kann das Spring-Framework das Paar (Schnittstelle, Implementierung) ermitteln. Wenn der Komponentenscan nicht aktiviert ist, müssen Sie die Bean explizit in Ihrer application-config.xml (oder einer entsprechenden Spring-Konfigurationsdatei) definieren.

Benötige ich @Qualifier oder @Resource?

Sobald Sie mehr als eine Implementierung haben, müssen Sie jede davon qualifizieren. Während der automatischen Verkabelung müssen Sie die @QualifierAnnotation verwenden, um die richtige Implementierung zusammen mit der @AutowiredAnnotation einzufügen. Wenn Sie @Resource (J2EE-Semantik) verwenden, sollten Sie den Bean-Namen mithilfe des nameAttributs dieser Anmerkung angeben .

Warum verdrahten wir die Schnittstelle automatisch und nicht die implementierte Klasse?

Erstens ist es immer eine gute Praxis, auf Schnittstellen im Allgemeinen zu codieren. Zweitens können Sie im Falle eines Frühlings jede Implementierung zur Laufzeit einfügen. Ein typischer Anwendungsfall ist das Einfügen einer Scheinimplementierung während der Testphase.

interface IA
{
  public void someFunction();
}


class B implements IA
{
  public void someFunction()
  {
    //busy code block
  }
  public void someBfunc()
  {
     //doing b things
  }
}


class C implements IA
{
  public void someFunction()
  {
    //busy code block
  }
  public void someCfunc()
  {
     //doing C things
  }
}

class MyRunner
{
     @Autowire
     @Qualifier("b") 
     IA worker;

     ....
     worker.someFunction();
}

Ihre Bean-Konfiguration sollte folgendermaßen aussehen:

<bean id="b" class="B" />
<bean id="c" class="C" />
<bean id="runner" class="MyRunner" />

Wenn Sie alternativ den Komponentenscan für das Paket aktiviert haben, in dem diese vorhanden sind, sollten Sie jede Klasse @Componentwie folgt qualifizieren:

interface IA
{
  public void someFunction();
}

@Component(value="b")
class B implements IA
{
  public void someFunction()
  {
    //busy code block
  }
  public void someBfunc()
  {
     //doing b things
  }
}


@Component(value="c")
class C implements IA
{
  public void someFunction()
  {
    //busy code block
  }
  public void someCfunc()
  {
     //doing C things
  }
}

@Component    
class MyRunner
{
     @Autowire
     @Qualifier("b") 
     IA worker;

     ....
     worker.someFunction();
}

Dann workerin MyRunnermit einer Instanz des Typs injiziert werden B.

Es kann auch einige Warnungen in Protokollen wie a verursachen Warnungen Cglib2AopProxy-Proxy-Methode . Und viele andere Gründe dafür werden hier beschrieben. Warum immer einzelne Implementierungsschnittstellen in Service- und Dao-Schichten?