Tapestry 5 - Die Entwicklung von Webanwendungen mit Leichtigkeit!
29,95€
(Preis inkl. Mwst. )
| Autor(en): | Igor Drobiazko |
| Verlag: | Addison-Wesley Verlag |
| Version: | 1. Auflage, 2009 |
| Umfang: | 434 Seiten |
| Format: | PDF: 4,01MB |
| Gewicht: | 926 g |
| ISBN: | 3827328446 |
| Bestell-Nr.: | 82732844P |
| Artikeltyp: | E-Book |
Tapestry ist ein komponentenorientiertes MVC-Framework zur Entwicklung von dynamischen und skalierbaren Web-Anwendungen in Java. Durch "Best Practices" wie RESTful URLs, Convention over Configuration und DRY (Don`t Repeat Yourself) vereinfacht Tapestry die Webentwicklung unter Java. Das Buch "Tapestry - Entwicklung von Webanwendungen mit Leichtigkeit" bietet dem Leser einen schnellen und praxisnahen Einstieg in das Tapestry-Framework. Anhand vieler Beispiele, Kochrezepte und Praxistipps wird Tapestry schrittweise erläutert. Dieses Buch wendet sich an alle Java-Entwickler, sowohl Einsteiger als auch Profi, die Webanwendungen mit minimalem Aufwand und hohem Maß an Produktivität entwickeln möchten. Kenntnisse in Java und HTML werden dabei vorausgesetzt.
Leseprobe:
17 Tapestry IoC und Dependency Injection (S. 327-329)
17.1 Einführung
Obwohl schon im Jahre 1988 von Ralph E. Johnson und Brian Foote im Journal of Object-Oriented Programming beschrieben, erfreuen sich Inversion of Control (IoC) und Dependency Injection (DI) erst seit Kurzem großer Beliebt- und Bekanntheit. Die beiden Begriffe werden oft wie Synonyme behandelt und missinterpretiert. Eine gute Beschreibung von IoC und DI ist im Artikel »Inversion of Control Containers and the Dependency Injection pattern« von Martin Fowler zu finden23. In diesem Kapitel werden zunächst die beiden Begriffe IoC und DI kurz erläutert und anschließend der IoC Container von Tapestry ausführlich beschrieben. Neben Tapestry IoC wurden in den letzten Jahren viele andere Container entwickelt. Der wohl bekannteste IoC/DI Container ist Spring IoC24. Daneben existieren unter anderem Pico- Container, HiveMind (in Tapestry 4 eingesetzt) und Google Guice.
17.2 Inversion of Control
Inversion of Control ist ein Prinzip in der Softwareentwicklung, bei dem Sie die Kontrolle über Code (z. B. Methodenaufrufe) an ein Framework oder eine API übergeben. Dieses Prinzip ist auch als Hollywood-Prinzip bekannt: »Don’t call us, we call you«. Die Übergabe der Kontrolle an das Framework kann beispielsweise durch die Implementierung bestimmter Superklassen erfolgen. Das Entwurfsmuster Template Method ist ein gutes Beispiel dafür. Dabei schreibt eine Superklasse die Implementierung von vordefinierten abstrakten Methoden vor, die zu bestimmten Zeitpunkten vom Framework aufgerufen werden. Die implementierende Klasse übergibt somit die Kontrolle an das Framework. Ein Beispiel für Inversion of Control ist die Servlet-API. Wenn Sie ein Servlet entwickeln, müssen Sie die vorgeschriebenen Methoden doPost() und/oder doGet() implementieren. Zwar sind Sie für die Implementierung der Geschäftslogik eines Servlets verantwortlich, doch der Kontrollfluss des Servlets wird vom Servlet-Container bestimmt. Erhält der Container eine Anfrage, wird er eine der beiden Methoden aufrufen, um die Anfrage zu behandeln.
17.3 Dependency Injection
Dependency Injection ist eine spezielle Form von IoC. In diesem Fall bedeutet die Umkehrung der Kontrolle, dass die Geschäftsobjekte nicht für die Verwaltung ihrer Abhängigkeiten zuständig sind. Stattdessen werden diese Abhängigkeiten injiziert. Es gibt dabei drei Arten:
- Setter-Injektion.
- Konstruktor-Injektion.
- Feld-Injektion.
17.3.1 Setter-Injektion
Bei der Setter-Injektion werden die Abhängigkeiten eines Geschäftsobjektes entsprechend der JavaBean-Konvention durch die Eigenschaften dieses Objektes spezifiziert. Direkt nach der Erzeugung einer Instanz des Geschäftsobjektes werden die Abhängigkeiten durch die Aufrufe der jeweiligen Setter-Methoden gesetzt. In Listing 17.1 hängt BusinessObjectImpl von DataSource ab. Diese Abhängigkeit wird durch den Aufruf der Setter-Methode setDataSource() aufgelöst. Der Vorteil dieser Art der Injektion besteht darin, dass das Geschäftsobjekt der JavaBean-Konvention entsprechen kann. Außerdem können Abhängigkeiten auch in Unterklassen des jeweiligen Geschäftsobjektes injiziert werden, ohne dass Sie zusätzlichen Code dafür schreiben müssen. Diese Art der Injektion sollte vermieden werden, falls nach dem Setzen aller Abhängigkeiten eine Initialisierung stattfinden soll. In diesem Fall sollten Sie die Konstruktor- Injektion vorziehen.
Leseprobe:
17 Tapestry IoC und Dependency Injection (S. 327-329)
17.1 Einführung
Obwohl schon im Jahre 1988 von Ralph E. Johnson und Brian Foote im Journal of Object-Oriented Programming beschrieben, erfreuen sich Inversion of Control (IoC) und Dependency Injection (DI) erst seit Kurzem großer Beliebt- und Bekanntheit. Die beiden Begriffe werden oft wie Synonyme behandelt und missinterpretiert. Eine gute Beschreibung von IoC und DI ist im Artikel »Inversion of Control Containers and the Dependency Injection pattern« von Martin Fowler zu finden23. In diesem Kapitel werden zunächst die beiden Begriffe IoC und DI kurz erläutert und anschließend der IoC Container von Tapestry ausführlich beschrieben. Neben Tapestry IoC wurden in den letzten Jahren viele andere Container entwickelt. Der wohl bekannteste IoC/DI Container ist Spring IoC24. Daneben existieren unter anderem Pico- Container, HiveMind (in Tapestry 4 eingesetzt) und Google Guice.
17.2 Inversion of Control
Inversion of Control ist ein Prinzip in der Softwareentwicklung, bei dem Sie die Kontrolle über Code (z. B. Methodenaufrufe) an ein Framework oder eine API übergeben. Dieses Prinzip ist auch als Hollywood-Prinzip bekannt: »Don’t call us, we call you«. Die Übergabe der Kontrolle an das Framework kann beispielsweise durch die Implementierung bestimmter Superklassen erfolgen. Das Entwurfsmuster Template Method ist ein gutes Beispiel dafür. Dabei schreibt eine Superklasse die Implementierung von vordefinierten abstrakten Methoden vor, die zu bestimmten Zeitpunkten vom Framework aufgerufen werden. Die implementierende Klasse übergibt somit die Kontrolle an das Framework. Ein Beispiel für Inversion of Control ist die Servlet-API. Wenn Sie ein Servlet entwickeln, müssen Sie die vorgeschriebenen Methoden doPost() und/oder doGet() implementieren. Zwar sind Sie für die Implementierung der Geschäftslogik eines Servlets verantwortlich, doch der Kontrollfluss des Servlets wird vom Servlet-Container bestimmt. Erhält der Container eine Anfrage, wird er eine der beiden Methoden aufrufen, um die Anfrage zu behandeln.
17.3 Dependency Injection
Dependency Injection ist eine spezielle Form von IoC. In diesem Fall bedeutet die Umkehrung der Kontrolle, dass die Geschäftsobjekte nicht für die Verwaltung ihrer Abhängigkeiten zuständig sind. Stattdessen werden diese Abhängigkeiten injiziert. Es gibt dabei drei Arten:
- Setter-Injektion.
- Konstruktor-Injektion.
- Feld-Injektion.
17.3.1 Setter-Injektion
Bei der Setter-Injektion werden die Abhängigkeiten eines Geschäftsobjektes entsprechend der JavaBean-Konvention durch die Eigenschaften dieses Objektes spezifiziert. Direkt nach der Erzeugung einer Instanz des Geschäftsobjektes werden die Abhängigkeiten durch die Aufrufe der jeweiligen Setter-Methoden gesetzt. In Listing 17.1 hängt BusinessObjectImpl von DataSource ab. Diese Abhängigkeit wird durch den Aufruf der Setter-Methode setDataSource() aufgelöst. Der Vorteil dieser Art der Injektion besteht darin, dass das Geschäftsobjekt der JavaBean-Konvention entsprechen kann. Außerdem können Abhängigkeiten auch in Unterklassen des jeweiligen Geschäftsobjektes injiziert werden, ohne dass Sie zusätzlichen Code dafür schreiben müssen. Diese Art der Injektion sollte vermieden werden, falls nach dem Setzen aller Abhängigkeiten eine Initialisierung stattfinden soll. In diesem Fall sollten Sie die Konstruktor- Injektion vorziehen.

