OpenSessionInView vs PersistentContext (Erweitert)

Question

Ich arbeite an einer Architektur Hibernate/JPA/Spring/Zk, und ich multipliziere die Fragen in diesen Tagen, weil ich viel Framework lernen muss.

Ich habe eine Frage, die mich für mehrere Tage perplex lässt.

Ich höre über das "Muster" OpenSessionInView, um eine Hibernate-Transaktion am Leben zu erhalten, um lazy loading zu machen. Viele sagen auch, dass das Muster nicht sehr sauber ist.

Und auf der anderen Seite heißt es, dass PersistentContext erweitert nicht threadsicher ist und daher nicht geeignet ist, den EntityManager am Leben zu erhalten.

Also, was ist die wirkliche Lösung für diese Probleme? Ich nehme an, dass diese Probleme von der Einführung von Ajax, die mehr Möglichkeiten, insbesondere mit der Verwendung von Lazy Loading, um einige schwere Sammlungen bei Bedarf zu laden ermöglicht.

Für den Moment habe ich @PersistenceContext im erweiterten Modus versucht. Es funktioniert ... Ich musste es für meine JUnit-Tests einstellen, und es funktioniert auch in meiner Webanwendung mit Lazy Loading ohne weitere Konfigurationen.

Ist die Entwicklung von Framework (Spring, JPA 2.0) bedeutet, dass es jetzt leichter und "sauberer" mit PersistentContext funktioniert?

Wenn dies nicht der Fall ist, sollten wir den OpenSessionInViewFilter von Spring verwenden und den PersistentContext im Transaktionsmodus ersetzen?

Vielen Dank.

Answer 1

Ich höre dich. Ich habe beide Muster seit 2008 in mehreren Anwendungen implementiert. Jetzt gebe ich alle bekannten Muster ganz auf. Wenn Sie dem Client einen Status zuweisen, stellen Sie Probleme mit Skalierbarkeit und Zustandsverwaltung dar: Verschmelzen Sie im Client, speichern Sie in Benutzersitzung, was passiert, wenn Sie durch einen Assistenten gehen und das Objekt vor dem Speichern vorübergehend sein muss? Wie würden Sie den Zustand von Client und Server synchronisieren? Was passiert, wenn db sich ändert - bricht der Client?

Betrachten Sie den Trend der bestehenden Technologien, einschließlich Spring MVC: Das Muster ist, zwei Projekte zu erstellen: 1) erholsame Webservices 2) Benutzeroberflächen. Der Status wird über ein unveränderbares Domänenmodell freigegeben. Sicher, Sie könnten am Ende eine Reihe von Dtos pflegen, aber sie sind vorhersehbar, billig und unbegrenzt skalierbar.

Meine Empfehlung? Vermeiden Sie das Senden von Proxy-Objekten über die Verbindung und die Behandlung von dtos auf dem Client oder die gemeinsame Nutzung eines Domänenmodells mit dem Client, wenn Sie serverseitige Validierungen erneut verwenden möchten. Lazy-Sammlungen können über feinkörnige API-Aufrufe über Ajax geladen werden. Auf diese Weise geben Sie dem Kunden die vollständige Kontrolle.

So ist das Social Web in den letzten fünf Jahren gewachsen.