# Hibernate-Designfrage zu Klassen



## y0dA (23. Jan 2008)

Hi!

Also ich habe bei mir für fast jede Tabelle ein Java Klassen äquivalent, nun meine Frage, "darf" ich jene Klassen nur in DAOS und Models benutzen oder auch bspw. in einem Controller --> bei Model-View-Controller Prinzip?`

Wenn ja, könne so eine Java Klasse, die eine Tabelle repräsentiert auch Objekte besitzen, welche in der Datenbank nicht existent sind sowie dürfen in jener Klasse auch Businesslogik für dieses Model reingeschrieben werden?

Im Moment habe ich es so, dass ich für jede Tabelle eine Java Klasse (nur mit getter/setter und constructor) und ein mapping file sowie eine dao Klasse habe. Mein Problem ist dass ich aber zu diesen Java Klassen auch "Businesslogik" brauche bzw Objekte, welche nicht in der DB existent sind bzw. weiß ich auch nicht ob ich diese Klassen "überall" benutzen darf (sauberes Design).


----------



## byte (23. Jan 2008)

y0dA hat gesagt.:
			
		

> Also ich habe bei mir für fast jede Tabelle ein Java Klassen äquivalent, nun meine Frage, "darf" ich jene Klassen nur in DAOS und Models benutzen oder auch bspw. in einem Controller --> bei Model-View-Controller Prinzip?


MVC sagt nichts über Persistenz aus. Für gewöhnlich gehört Persistenz zur Modellschicht. Natürlich kannst Du an die DB gebundene Klassen auch im Controller verwenden. Das ist ja auch der Sinn der Sache, dass man die Daten dann irgendwie anzeigt.



> Wenn ja, könne so eine Java Klasse, die eine Tabelle repräsentiert auch Objekte besitzen, welche in der Datenbank nicht existent sind sowie dürfen in jener Klasse auch Businesslogik für dieses Model reingeschrieben werden?


Klar. Einfach mit @Transient markieren, so dass Hibernate sie beim Mapping ignoriert.



> Im Moment habe ich es so, dass ich für jede Tabelle eine Java Klasse (nur mit getter/setter und constructor) und ein mapping file sowie eine dao Klasse habe. Mein Problem ist dass ich aber zu diesen Java Klassen auch "Businesslogik" brauche bzw Objekte, welche nicht in der DB existent sind bzw. weiß ich auch nicht ob ich diese Klassen "überall" benutzen darf (sauberes Design).


Es gibt da sicher viele Ansätze. Prinzipiell spricht nichts dagegen, die Business Logik in die Datenobjekte zu schreiben, das ist ja der objektorientierte Weg. Du kannst natürlich die Beans auch sauber von dem Code halten und diese per Komposition in Deine Business Objekte integrieren. Wenn Du Delegates für die Getter und Setter schreibst, macht das prinzipiell keinen Unterschied in der Verwendbarkeit der Objekte.


----------



## y0dA (23. Jan 2008)

Würdest du auch in der Businesslogik die Persistierung durchführen? Sprich session.save etc, oder das in entsprechenden DAO Klassen oder Persistenzklassen durchführen?

btw ich benutze hbm Files und keine Annotations

mfg


----------



## byte (23. Jan 2008)

Auf jeden Fall DAOs!


----------



## y0dA (23. Jan 2008)

Super danke.


----------

