✔ DependencyInjection vs. ServiceLocator

[chickenwings]

Hallo,

ich habe nun schon öfter gelesen, dass mit EJB 3 das ServiceLocator Pattern ausgedient haben soll. Leider finde ich keine Beispiele, die auf mein Problem passen.

Ich habe einen Client, der über ein ServiceLocator die SessionBean lokalisiert.
Wie würde denn das jetzt mittels Dependency Injection gehen?
Kann mir jemand ein Beispiel zeigen?

Grüsse,
chickenwings

 

[Oliver Gierke]

public class WithServiceLocator {

  public WithServiceLocator() {
    ServiceLocator locator = ServiceLocator.getInstance();
    DeineKomponente komponente = locator.getKomponente("komponente");
  }
}

Nachteile:
- Abhängigkeit zum ServiceLocator (zu einem Technischen API)
- dadurch "keine" Testbarkeit
- Abhängigkeit zur Infrastruktur (ServiceLocator arbeitet meist gegen das JNDI - und das hast du nicht in Testumgebungen)
- VERSTECKTE Abhängigkeit, Clients deiner Klasse wissen nichts von der Abhängigkeit zum Servicelocator

public class MitDependencyInjection() {

  public void setDeineKomponente(DeineKomponente komponente) {
    // setzen der Variable
  }
}


public class Container() {

  public static void main(String... args) {
    DeineKomponente komponente = new DeineKomponenteImpl();
   
    MitDependencyInjection foo = new MitDependencyInjection();
    foo.setDeineKomponente(komponente);

    foo.dooSomething();
  }
}

Vorteile bzgl. MitDependencyInjection:
- explizite Offenlegung der Dependency (am Setter erkennbar)
- einzige Abhängigkeit zum Kollaborateur, nicht zu einem technischen API
- dadurch unabhängig von der Plattform
- Testbar durch Injektionsmöglichkeit eines Mocks oder Stubs

"Nachteil":
- Container (hier in Form einer Klasse) notwendig (gibts in unterschiedlich komfortablen und umfangreichen Ausführungen (Pico- bzw. NanoContainer, Guice, Spring, EJB3 usw.)

Hier haben wir DI bzw. Spring schonmal recht ausführlich diskutiert. EJB3 kann halt leider nur DI für EE Komponenten (Servlets, SessionBeans, MessageDrivenBeans).

Gruß
Ollie

 

[Cojote]

Wenn der Client ein "normales" Java Programm oder ein Konsolenprogramm ist kannst du den Application Client Container deines Application Servers nutzen.
Der ermöglicht dir dann auch DI einer entfernten EJB in deinen Clientcode.
Ein ServiceLocator auf Client Seite ist also nur dann nicht notwendig wenn du deinen Client im AppClient Container betreibst.

 

[chickenwings]

Hallo,

danke für die ausführlichen Antworten. Um möglichts flexibel zu sein und unabhängig von der Architektur ist es wohl sinnvoller, meine SessionBeans über einen ServiceLocator auzurufen.

Danke,
chickenwings

 

[Oliver Gierke]

Um möglichts flexibel zu sein und unabhängig von der Architektur ist es wohl sinnvoller, meine SessionBeans über einen ServiceLocator auzurufen.

Ich versteh nicht wirklich, wie du aus den bisherigen Posts dieses Fazit ziehen kannst. Du kommst zum genau entgegengesetzen Schluss. Irgendwie komisch . Sicher, dass du uns richtig verstanden hast?

Gruß
Ollie