2012-01-22

Ultimate Swing, Teil 18

Im vorangehenden Beitrag hatte ich Ihnen das Business Delegate Muster nahegelegt und eine Beispiel-Implementierung gezeigt. Es gibt Ihnen die Möglichkeit, die Präsentationsschicht fachlich anders zu strukturieren, als es die Geschäftslogik (das Backend) vielleicht vorsieht. Dies ist unter anderem der Fall, wenn Ihre Anwendung eine Art Mashup realisiert, also die Ergebnisse verschiedener Serviceaufrufe kombiniert.

Achtung: Es ist natürlich nicht originäre Aufgabe der Präsentationsschicht, Services zu orchestrieren. In einer Enterpriseanwendung würde selbstverständlich das Backend dies übernehmen. Mein Szenario geht davon aus, dass Sie keine klassische verteilte Anwendung bauen möchten, sondern “nur” externe Dienste nutzen (also eigentlich einen Fat Client coden).

Fazit: Der Business Delegate kommt aus der Enterprise-Welt, kann uns aber auch bei klassischen Desktop-Anwendungen helfen, sofern diese fremde Services nutzen. Dann fungiert er für uns als eine Art Übersetzer, der die Daten für das eigene Programm anpasst.

Sind Sie dem Link etwas weiter oben gefolgt? Falls nicht, sollten Sie dies nun nachholen und nach der Lektüre wieder hier aufschlagen.
Smiley

Wie Sie nun wissen, nutzt der Business Delegate weitere core J2EE Patterns. Falls dieses Buch noch nicht in Ihrem Regal steht, sollten Sie es auf jeden Fall kaufen. Zugegebenermaßen ist das Werk nicht mehr taufrisch, aber es ist auch heute noch eine Quelle der Inspiration. Einige Muster haben an Bedeutung verloren oder werden heute überhaupt nicht mehr eingesetzt, andere sind aktuell wie immer. Zum Beispiel der Service Locator. Er verbirgt die Implementierung der Suche nach Services und Komponenten und stellt (zum Beispiel einem Business Delegate) eine einheitliche Zugriffsschicht auf Services zur Verfügung. Die folgende Implementierung ist insofern ein klein wenig untypisch, als Sie keine JEE-typischen Lookup-Strategien entdecken werden. Das Vorgehen (zum Beispiel Realisierung als Singleton) ist aber identisch.

public class ServiceLocator {

  private static final ServiceLocator INSTANCE = new ServiceLocator();

  private CategoryService categoryService;
  private TasksService tasksService;

  private ServiceLocator() {
    categoryService = null;
    tasksService = null;
  }

  public static ServiceLocator getInstance() {
    return INSTANCE;
  }

  public synchronized CategoryService getCategoryService() {
    if (categoryService == null) {
      categoryService = new LocalCategoryService();
    }
    return categoryService;
  }

  public synchronized TasksService getTasksService() {
    if (tasksService == null) {
      tasksService = new LocalTasksService();
    }
    return tasksService;
  }
}

Die Nutzung des Service Locators durch den Business Delegate CategoryDelegate sieht folgendermaßen aus:

  private CategoryService categoryService;

  public CategoryDelegate() {
    categoryService = ServiceLocator.getInstance().getCategoryService();
  }

Über die Vorteile der Nutzung eines Service Locators ist viel geschrieben worden. Das für mich überzeugendste Argument, ihn zu nutzen, ist die leichte Austauschbarkeit der Serviceimplementierung. Wie Sie gesehen haben, liefert meine Implementierung beim Aufruf von getCategoryService() ein Objekt des Typs LocalCategoryService. Wenn wir später auf Google Konten umsteigen, wird hier einfach ein anderes Objekt geliefert. Wichtig ist nur, dass alle Implementierungen eine gemeinsame Schnittstelle haben. Diese wird üblicherweise durch ein Interface beschrieben, beispielsweise CategoryService. Gerade bei echten verteilten Anwendungen ist diese Austauschbarkeit ein Segen – solange die Serviceimplementierung selbst noch im Gange ist, kann die Präsentationsschicht gegen Mocks arbeiten.

No comments:

Post a Comment