Warum wird buildSessionFactory() durch buildSessionFactory(ServiceRegistry) ersetzt? Was ist die Wichtigkeit von ServiceRegistry?
Die Gründe dafür sind auf Hibernate Jira
erklärtGegenwärtig wird eine SessionFactory erstellt, indem man eine Menge Zeug in ein Konfigurationsobjekt wirft, es umrührt, es zum Kochen bringt und dann die SessionFactory herauszieht. Im Ernst, es gibt ein paar Probleme mit der Art, wie wir derzeit in einer Konfiguration arbeiten und wie wir sie verwenden, um eine SessionFactory zu erstellen: Das allgemeine Problem, dass es keinen "Lebenszyklus" gibt, wenn verschiedene Informationen verfügbar sein werden. Dies ist eine wichtige Auslassung in vielerlei Hinsicht: 1) betrachte Schema-Generierung. Derzeit können wir den Dialekt nicht einmal kennen, wenn viele db-Objektnamen ermittelt werden. das wäre schön, weil es uns erlauben würde, Tabellen- / Spaltennamen transparent zu behandeln, die zum Beispiel auch Schlüsselwörter / reservierte Wörter im Dialekt sind. 2) Statik von Typen und Typzuordnungen. Weil wir momentan nichts haben, um sie zu erfassen. Idealerweise würde eine Typinstanz die SessionFactory kennen, an die sie gebunden ist. Was wir jetzt haben, ist vielmehr, die API-Methoden relativ oft zu ändern, um die SessionFactory als übergebenen Parameter hinzuzufügen, sobald festgestellt wird, dass sie benötigt wird. 3) auch die meisten (alle?) Der "statischen" Konfigurationsparameter in Hibernate müssen aktuell so sein, weil sie von diesen statischen Typen verwendet werden; Mit den Scoping-Typen können wir also auch diese Konfigurationsparameter definieren (Dinge wie Bytecode-Provider, Verwendung von Binärströmen usw.). Im Idealfall sehe ich ein Schema, bei dem Benutzer selbst eine Instanz org.hibernate.cfg.Settings (oder etwas Ähnliches) erstellen. Außerdem würden sie Metadaten auf eine Art von Registry anwenden (nennen wir es jetzt MetadataRegistry). Um dann eine SessionFactory zu erstellen, würden sie diese beiden Informationen liefern (via ctor? Via Builder?). Der wichtige Aspekt ist jedoch, dass die Informationen in MetadataRegistry bis zu diesem Zeitpunkt nicht behandelt werden, um zu gewährleisten, dass das Auflösen von Schemaobjektnamen, -typen usw. auf die Laufzeiteinstellungen (und insbesondere den Dialekt) zugreifen kann / p>
Sie können auch Kommentare zu diesem hier lesen: Ссылка Es ist zu viel, um Paste zu kopieren, und ich denke, Jira wird nicht untergehen, damit diese Antwort gültig sein sollte.