# JPA - Read-Only-Objekte



## Landei (22. Nov 2010)

Manchmal ist es bequem, Objekte mit JPA aus der Datenbank zu holen, die ich in der aktuellen Anwendung gar nicht verändern möchte (oder nur bestimmte Felder). Nun erfordert JPA ja, dass die Objekte den Bean-Spezifikationen gehorchen, also Setter benötigen. Gibt vielleicht einen Trick, vollständig oder teilweise unveränderliche Objekte zu erzeugen, ohne auf die Bequemlichkeiten von JPA verzichten zu müssen?

Eine Variante wäre, mit Interfaces zu arbeiten:


```
interface Foo {
   String getId();
   String getName();
}

@Entity
class FooImpl extends Foo {
    String id;
    String name;

    @Id
    public String getId() { return id; }
    public void setId(String id) { this.id = id; }

    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
 
}
```

"Normaler" Code würde dann nur das Interface zu Gesicht bekommen. Allerdings schreckt mich der Aufwand, für jede Klasse ein extra Interface zu basteln, etwas ab.


----------



## MySelV (22. Nov 2010)

Hi,

im Netz fand ich gerade das: LINK.
Wenn du TopLink / EclipseLink als Implementierung von JPA verwendest, sollte das gehen. Bei Hibernate gibt es vielleicht was ähnliches..

Grüße
Erik


----------



## Landei (22. Nov 2010)

Ich habe eine der genannten Alternativen übernommen (wußte gar nicht, dass es das gibt):


```
@Column(name = "foo", insertable = false, updatable = false)
```

Funktioniert leider nicht für die @Id-Spalte.


----------



## SlaterB (22. Nov 2010)

wenn gar niemand die Objekte je ändern soll (nur in der DB vorgegeben?), wie siehts dann mit setter weglassen oder private/protected/leer aus?


----------



## Landei (22. Nov 2010)

Dann hebt EclipseLink die Hufe hoch...


----------



## maki (22. Nov 2010)

Landei hat gesagt.:


> Ich habe eine der genannten Alternativen übernommen (wußte gar nicht, dass es das gibt):
> 
> 
> ```
> ...


Die ID Spalte sollte auch nie Immutable sein, weil damit keinen neuen Objekte erzeugt & persistiert werden können, oder verstehe ich dich falsch?

Ansonsten ist eben die Interface Variante (Eines nur zum Llesen, eines zum lesen + schreiben) eine Möglichkeit.


----------



## XHelp (22. Nov 2010)

Hilft ggf Empty constructors and setters on JPA Entites - efreedom weiter? Oder ist das die Alternative, die du meintest?


----------



## Landei (22. Nov 2010)

Tatsache, das ist ja obercool! Einfach die Instanzvariablen annotieren, dann kann man die Setter weglassen. Bin gar nicht auf die Idee gekommen, das zu probieren.


----------



## mvitz (22. Nov 2010)

Und laut dem aktuellen JavaEE Spezial Heft, muss der Defaultkonstruktor nichtmal "public" sein, somit ließe sich dann eine nach Außen Immutable Klasse abbilden (auch wenn die Felder nicht final sein können)


----------

