Kolumne: Enterprise Tales

Kolumne: Enterprise Tales

Arne Limburg, Lars Röwekamp


Für statische Abfragen ist in der heutigen Toolwelt eine recht gute Unterstützung zur Vermeidung von Tipp- und/oder Semantikfehlern vorhanden. Die meisten IDEs können mittlerweile JPQL-Abfragen bereits zur Entwicklungszeit analysieren und dann nicht nur direkt auf Syntaxfehler hinweisen, sondern finden sogar Unstimmigkeiten mit dem verwendeten JPA-Modell (falsche Entity-Namen, falsch verwendete Attribute etc.).Auch wenn einige IDEs noch Schwierigkeiten haben, einen JPQL-String zu erkennen, wenn er direkt an entityManager.createQuery(...) übergeben wird, gelingt es mit den entsprechenden Plug-ins mittlerweile jeder IDE @NamedQueries(...) zu parsen und dort Fehler zu erkennen. In Eclipse z. B. muss man dazu nur das JPA-Facet aktivieren. Schon alleine deshalb lohnt es sich, Named Querys den Vorzug vor Querys zu geben, die man direkt über entityManager.createQuery(...) ausführt. Vor diesem Hintergrund könnte man auf die Idee kommen, auch obigen Use Case mit Named Querys abzubilden. Man bräuchte ja nur drei Stück: eine, die nur nach dem Vornamen sucht, eine, die nur nach dem Nachnamen sucht, und eine, die nach Vor- und Nachnamen sucht.Wenn es sich bei den optionalen Parametern nur um Vor- und Nachnamen handelt, mag das ja noch funktionieren. Man stößt mit diesem Vorgehen aber recht schnell an Grenzen. Spätestens ab dem dritten optionalen Parameter erhöht sich die Anzahl der benötigten Abfragen auf sieben, und man benötigt eine andere Technik, um die Abfrage zu definieren.Auch der Ansatz, eine solche Anforderung über String-Konkatenation zu lösen, ist auf Dauer zum Scheitern verurteilt, weil die Wartbarkeit enorm leidet. Ganz zu schweigen davon, dass man damit in der Regel alle oben genannten Syntax- und Semantikchecks der IDE sofort aushebelt. Wie also soll dann mit einer solchen Situation umgegangen werden? Das Criteria APIEtwas merkwürdig mutet beim Criteria API allerdings der Zugriff auf Attribute eines Objekts an: person.get(Person_.firstName). Die Klasse Person_ (nein, der Unterstrich ist kein Tippfehler) ist dabei eine automatisch generierte Klasse des ebenfalls mit JPA 2.0 eingeführten Metamodells, die typsicheren Zugriff auf eben diese Attribute bieten soll. Der leichter zu lesende Zugriff über die Angabe des Attributnamens als String, also person.get("firstName") ist zwar auch möglich und auch deutlich lesbarer, schützt aber nicht vor Tipp­fehlern. Der etwas komplizierte Zugriff auf Attribute einer abzufragenden Entität über das Metamodell ist auch ...

Kolumne: Enterprise Tales

Kolumne: Enterprise Tales

Arne Limburg, Lars Röwekamp


Für statische Abfragen ist in der heutigen Toolwelt eine recht gute Unterstützung zur Vermeidung von Tipp- und/oder Semantikfehlern vorhanden. Die meisten IDEs können mittlerweile JPQL-Abfragen bereits zur Entwicklungszeit analysieren und dann nicht nur direkt auf Syntaxfehler hinweisen, sondern finden sogar Unstimmigkeiten mit dem verwendeten JPA-Modell (falsche Entity-Namen, falsch verwendete Attribute etc.).Auch wenn einige IDEs noch Schwierigkeiten haben, einen JPQL-String zu erkennen, wenn er direkt an entityManager.createQuery(...) übergeben wird, gelingt es mit den entsprechenden Plug-ins mittlerweile jeder IDE @NamedQueries(...) zu parsen und dort Fehler zu erkennen. In Eclipse z. B. muss man dazu nur das JPA-Facet aktivieren. Schon alleine deshalb lohnt es sich, Named Querys den Vorzug vor Querys zu geben, die man direkt über entityManager.createQuery(...) ausführt. Vor diesem Hintergrund könnte man auf die Idee kommen, auch obigen Use Case mit Named Querys abzubilden. Man bräuchte ja nur drei Stück: eine, die nur nach dem Vornamen sucht, eine, die nur nach dem Nachnamen sucht, und eine, die nach Vor- und Nachnamen sucht.Wenn es sich bei den optionalen Parametern nur um Vor- und Nachnamen handelt, mag das ja noch funktionieren. Man stößt mit diesem Vorgehen aber recht schnell an Grenzen. Spätestens ab dem dritten optionalen Parameter erhöht sich die Anzahl der benötigten Abfragen auf sieben, und man benötigt eine andere Technik, um die Abfrage zu definieren.Auch der Ansatz, eine solche Anforderung über String-Konkatenation zu lösen, ist auf Dauer zum Scheitern verurteilt, weil die Wartbarkeit enorm leidet. Ganz zu schweigen davon, dass man damit in der Regel alle oben genannten Syntax- und Semantikchecks der IDE sofort aushebelt. Wie also soll dann mit einer solchen Situation umgegangen werden? Das Criteria APIEtwas merkwürdig mutet beim Criteria API allerdings der Zugriff auf Attribute eines Objekts an: person.get(Person_.firstName). Die Klasse Person_ (nein, der Unterstrich ist kein Tippfehler) ist dabei eine automatisch generierte Klasse des ebenfalls mit JPA 2.0 eingeführten Metamodells, die typsicheren Zugriff auf eben diese Attribute bieten soll. Der leichter zu lesende Zugriff über die Angabe des Attributnamens als String, also person.get("firstName") ist zwar auch möglich und auch deutlich lesbarer, schützt aber nicht vor Tipp­fehlern. Der etwas komplizierte Zugriff auf Attribute einer abzufragenden Entität über das Metamodell ist auch ...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang