Überarbeitung des Hibernate Session-Scopes (Unit of Work)

[mcw]

Überlegungen zur Überarbeitung des Session-Scopes für Hibernate:

• Die HBM-Session wird aus dem UnDataAccess? entfernt.

• Ein neuer Session-Scope wird als UnitOfWork? definiert: ein UnitOfWork? Objekt kapselt z.B. die HibernateSession.

• Beim Holen des UnDataAccess? Objektes muss die UnitOfWork? mit angegeben werden: UnDataAccessFactory?.getInstance(xUnitOfWork).

• Der Workflow lädt seine Daten selbst: Beim Starten von neuen Workflows dürfen nur transiente Objekte (Objekte, die nicht an einen HBM-Session gebunden sind/waren) oder Datencontainer weitergereicht werden. Datenobjekte (Hibernate Objekte) müssen über den Primärschlüssel übergeben und im Workflow neu geladen werden.

• Ein Folgeworkflow mit eigener UnitOfWork? darf nur gestartet werden, wenn der auslösende Workflow gespeichert oder nicht dreckig (unverändert) ist.

• Beim Starten eines Folgeworkflows mit eigener UnitOfWork? muss der auslösende Workflow, bzw. das Element, an dem die UnitOfWork? hängt, gegen weiteres Bearbeiten gesperrt werden.

• Ausnahmen können nur Workflows sein, die selbst nur lesend auf Daten zufreifen (reine Listing-Workflows wie Trees oder Tables).

• Bei Änderungen des Folgeworkflows am Datenobjekt sollten die Daten im Aufrufer aktualisiert werden.

[mcw]

Es muss je UnitOfWork? einen DataAccess? geben. Dementsprechend wäre die UnitOfWork? lediglich ein Marker und könnte das gleiche Objekt sein.