Für meine GenericDAO will ich folgende Funktion implementieren
public int delete(Class<T> theClass, List<ID> ids, boolean deleted) {
String hsql = "UPDATE " + theClass.getName()
+ " SET deleted = '" + deleted + "' "
+ " WHERE id IN (" + StringUtils.implode(ids) + ")";
return this.executeHSQL(hsql);
}
public int publish(Class<T> theClass, List<ID> ids, boolean published) {
String hsql = "UPDATE " + theClass.getName()
+ " SET published = '" + published + "' "
+ " WHERE id IN (" + StringUtils.implode(ids) + ")";
return this.executeHSQL(hsql);
}
Ich möchte sicherstellen das die Entityklasse eine Column “deleted” definiert ist bei der Funktion “deleted” definiert ist.
Bzw. die Column “published” bei der Funktion “publish”.
Hierbei habe ich Entityklassen die weder über “deleted” noch “publsihed” verfügen. Andere Klassen die entweder nur über “deleted” oder “published” verfügen. Oder Klassen die über
beides Verfügen.
Wie kann ich soetwas ohne Java 8 am besten realisieren?
Der saubere Weg wäre, zwei Interfaces Publishable und Deleteable zu definieren, die jeweils eine Methode zum Setzen des Flags anbieten.
Die Persistierung würde ich dann das ORM-Framework machen lassen und keine SQL (oder HQL / JPQL) Abfrage schreiben.
Das hat ich mir auch überlegt. Die habe ich auch auch schon erstellt. Sie heissen bei mir „IDeletableTable“ und „IPublishableTable“. Das Problem ist nur
- wie stelle ich sicher das diese Methoden auch über z.B. @Column(name=„deleted“) verfügen.
- Zum anderen wie finde ich aus einem Interface heraus wie die Klasse heist, die ich in der Funktionsübergabe übergebe?
Kannst du mir hierzu genauere Angaben mach was du meinst?
Das sind mMn schlechte Namen. Das I ist überflüssig, weil man zum einen sofort sehen kann, dass es ein Interface ist (mit Hilfe der IDE) und zum anderen, weil es keine relevante Information ist. Der Typ des Parameters ist entscheidend - nicht, ob der Typ durch ein Interface oder eine Klasse definiert wurde. Das Suffix „Table“ würde ich auch weglassen. Dass es sich dabei um eine Tabelle handelt ist für die Funktionalität nicht relevant.
Ich verstehe nicht, wieso du das brauchst. Du machst die Persistenz normalerweile deklarativ. Also entweder über eine XML-Konfiguration oder mit Annotationen. Wenn du JPA nutzt, dann sorgt der Entitymanager (bei reinem Hibernate die Session) dafür, dass die Felder der Entity korrekt in der Datenbank landen, ohne dass du dafür mit SQL / HQL / JPQL in Berührung kommst. Wenn die Fähigkeit gelöscht oder veröffentlicht zu werden nur über das Interface angegeben wird, dann hast du alle Flexibilität, den Zustand je nach Anwendungsfall zu modellieren. In der jeweiligen Klasse kannst du die Spalte dann benennen wie du möchtest.
Auch da musst du dir keine Gedanken drüber machen. Deine publish und delete Methoden passen eher zu einem Active Record Pattern als zu einem OR-Mapping mit hibernate. Mit hibernate erledigt das der EntityManager bzw. die Session.
Falls du soetwas mal brauchen solltest, ginge das wohl über einen Parameter Class<T extends Deletable>.
Ansonsten kann ich @Landei nur zustimmen: Spring Data macht einem das Leben wirklich deutlich leichter. Du müsstest ggf. nur die Annotationen anpassen, damit du die JPA- statt der Hibernate-Versionen verwendest.