Der Unterschied zwischen Mybatis und Winterschlaf

Die beiden gängigen Framework-Kombinationen, die wir in der Java-Entwicklung verwenden, sind SSM, Spring, SpringMVC, MyBatis und SSH, Struts2, Spring und Hibernate. Heute werfen wir einen Blick auf die Unterschiede zwischen den beiden Datenbank-Frameworks.

Erster Aspekt: ​​Vergleich der Entwicklungsgeschwindigkeit

In Bezug auf die Entwicklungsgeschwindigkeit ist es schwieriger, Hibernate wirklich zu meistern als Mybatis manche. Das Mybatis-Framework ist relativ einfach und benutzerfreundlich, aber auch relativ grob. Persönlich denke ich, dass man, um Mybatis gut nutzen zu können, zunächst Hibernate verstehen muss. (Empfohlenes Lernen: Java Video Tutorial)

Beim Vergleich der Entwicklungsgeschwindigkeit der beiden müssen nicht nur die Eigenschaften und die Leistung der beiden berücksichtigt werden, sondern auch, worauf man achten sollte Es eignet sich besser für die Projektentwicklung, da in einem Projekt grundsätzlich keine komplexen Abfragen verwendet werden, sondern nur einfache Hinzufügungen, Löschungen, Änderungen und Abfragen Die grundlegenden SQL-Anweisungen wurden gekapselt, und Sie müssen überhaupt nicht dorthin gehen. Das Schreiben von SQL-Anweisungen spart viel Zeit, aber für ein großes Projekt gibt es viele komplexe Anweisungen, daher ist die Auswahl des Ruhezustands keine gute Wahl mybatis wird deutlich schneller und auch die Verwaltung von Kontoauszügen wird komfortabler.

Der zweite Aspekt: ​​Vergleich der Entwicklungsarbeitslast

Hibernate und MyBatis verfügen beide über entsprechende Tools zur Codegenerierung. Es können einfache und grundlegende DAO-Schichtmethoden generiert werden. Für erweiterte Abfragen erfordert Mybatis das manuelle Schreiben von SQL-Anweisungen und ResultMap. Hibernate verfügt über einen guten Zuordnungsmechanismus. Entwickler müssen sich nicht um die SQL-Generierung und Ergebniszuordnung kümmern und können sich mehr auf Geschäftsprozesse konzentrieren.

Der dritte Aspekt: ​​SQL-Optimierung

Die Hibernate-Abfrage fragt alle Felder in der Tabelle ab, was die Leistung verbraucht. Hibernate kann auch sein eigenes SQL schreiben, um die Felder anzugeben, die abgefragt werden müssen. Dies zerstört jedoch die Einfachheit der Hibernate-Entwicklung. Das SQL von Mybatis wird manuell geschrieben, sodass die Abfragefelder nach Bedarf spezifiziert werden können.

Die Optimierung von Hibernate HQL-Anweisungen erfordert das Ausdrucken der SQL, und die SQL von Hibernate wird von vielen Leuten nicht gemocht, weil sie zu hässlich ist. Das SQL von MyBatis wurde von mir manuell geschrieben und ist daher leicht anzupassen. Aber Hibernate verfügt über eigene Protokollstatistiken. Mybatis selbst verfügt über keine Protokollstatistiken und verwendet Log4j für die Protokollierung.

Aspekt 4: Vergleich der Objektverwaltung

Hibernate ist eine vollständige Objekt-/Relational-Mapping-Lösung, die die Funktion der Objektstatusverwaltung bietet über die Details des zugrunde liegenden Datenbanksystems. Mit anderen Worten: Im Vergleich zur gängigen JDBC/SQL-Persistenzschichtlösung, die SQL-Anweisungen verwalten muss, verwendet Hibernate eine natürlichere objektorientierte Perspektive, um Daten in Java-Anwendungen beizubehalten.

Mit anderen Worten: Entwickler, die Hibernate verwenden, sollten sich immer auf den Zustand des Objekts konzentrieren und müssen sich nicht um die Ausführung von SQL-Anweisungen kümmern. Diese Details werden von Hibernate bereits berücksichtigt und nur Entwickler müssen sie verstehen, wenn sie die Systemleistung optimieren. MyBatis verfügt in diesem Bereich über keine Dokumentation und Benutzer müssen die Objekte selbst im Detail verwalten.

Der fünfte Aspekt: ​​Caching-Mechanismus

Hibernate-Cache

Der Hibernate-Cache der ersten Ebene ist der Sitzungscache Die Verwendung des Caches der ersten Ebene muss für eine gute Verwaltung des Sitzungslebenszyklus erforderlich sein. Es wird empfohlen, eine Sitzung in einer Aktionsoperation zu verwenden. Der Cache der ersten Ebene erfordert eine strikte Sitzungsverwaltung.

Der Hibernate-Cache der zweiten Ebene ist ein Cache auf SessionFactory-Ebene. Der Cache von SessionFactory ist in integrierten Cache und externen Cache unterteilt. Der integrierte Cache speichert Daten, die in einigen Sammlungsattributen des SessionFactory-Objekts enthalten sind (Mapping-Elementdaten und geplante SQL-Anweisungen usw.). Er ist für Anwendungen schreibgeschützt. Der externe Cache speichert eine Kopie der Datenbankdaten und ähnelt in seiner Funktion dem First-Level-Cache. Neben der Verwendung von Speicher als Speichermedium kann der Second-Level-Cache auch externe Speichergeräte wie Festplatten verwenden. Der Cache der zweiten Ebene wird als Cache auf Prozessebene oder Cache auf SessionFactory-Ebene bezeichnet. Er kann von allen Sitzungen gemeinsam genutzt werden. Sein Lebenszyklus existiert und stirbt zusammen mit dem Lebenszyklus von SessionFactory.

MyBatis Cache

MyBatis enthält eine sehr leistungsstarke Abfrage-Caching-Funktion, die sehr einfach konfiguriert und angepasst werden kann. Viele Verbesserungen an der Cache-Implementierung in MyBatis 3 wurden implementiert, wodurch sie leistungsfähiger und einfacher zu konfigurieren ist.

Caching ist standardmäßig nicht aktiviert. Zusätzlich zum lokalen Sitzungs-Caching kann es die Monetarisierung verbessern und ist auch für die Handhabung zirkulärer Abhängigkeiten erforderlich. Um L2-Caching zu aktivieren, müssen Sie Ihrer SQL-Zuordnungsdatei eine Zeile hinzufügen:

Das ist im wahrsten Sinne des Wortes alles. Die Wirkung dieser einfachen Anweisung ist wie folgt:

Alle SELECT-Anweisungen in der Mapping-Anweisungsdatei werden zwischengespeichert.

Alle Anweisungen zum Einfügen, Aktualisieren und Löschen in der zugeordneten Anweisungsdatei leeren den Cache.

Der Cache wird mithilfe des Least-Recent-Used-Algorithmus (LRU, am wenigsten kürzlich verwendet) wiederhergestellt.

Gemäß dem Zeitplan (z. B. kein Spülintervall, kein Aktualisierungsintervall) wird der Cache nicht in chronologischer Reihenfolge geleert.

Der Cache speichert 1024 Verweise auf die Listensammlung oder das Objekt (unabhängig davon, was die Abfragemethode zurückgibt).

Der Cache wird als Lese-/Schreibcache betrachtet, was bedeutet, dass der Objektabruf nicht gemeinsam genutzt wird und von Aufrufern sicher geändert werden kann, ohne die Aktivitäten anderer Aufrufer oder Threads zu beeinträchtigen.

Alle diese Eigenschaften können über die Eigenschaften des Cache-Elements geändert werden.

Zum Beispiel:

Diese erweiterte Konfiguration erstellt einen FIFO-Cache. und wird alle 60 Sekunden aktualisiert, wodurch 512 Verweise auf das Ergebnisobjekt oder die Ergebnisliste gespeichert werden. Die zurückgegebenen Objekte gelten als schreibgeschützt, sodass ihre Änderung zwischen Aufrufern in verschiedenen Threads zu Konflikten führen kann. Die verfügbaren Räumungsstrategien sind, der Standardwert ist LRU:

LRU – Least Latest Used: Objekte entfernen, die am längsten nicht verwendet wurden.

FIFO – First in, first out: Objekte in der Reihenfolge entfernen, in der sie in den Cache gelangen.

SOFT – Soft-Referenz: Entfernt Objekte basierend auf dem Garbage-Collector-Status und Soft-Referenzregeln.

SCHWACH – Schwache Referenzen: Entfernen Sie Objekte aggressiver basierend auf dem Garbage-Collector-Status und schwachen Referenzregeln.

flushInterval kann auf jede positive Ganzzahl gesetzt werden und stellt einen angemessenen Zeitraum in Millisekunden dar. Der Standardwert ist nicht festgelegt, dh es gibt kein Aktualisierungsintervall und der Cache wird nur aktualisiert, wenn die Anweisung aufgerufen wird.

Größe (Anzahl der Referenzen) kann auf eine beliebige positive Ganzzahl festgelegt werden. Berücksichtigen Sie dabei die Anzahl der zwischengespeicherten Objekte und die Anzahl der verfügbaren Speicherressourcen in Ihrer laufenden Umgebung. Der Standardwert ist 1024.

readOnly-Attribut kann auf true oder false gesetzt werden. Ein schreibgeschützter Cache gibt an alle Aufrufer dieselbe Instanz des zwischengespeicherten Objekts zurück. Daher können diese Objekte nicht geändert werden. Dies bietet wichtige Leistungsvorteile. Ein Lese-/Schreibcache gibt eine Kopie des zwischengespeicherten Objekts zurück (über Serialisierung). Dies ist langsamer, aber sicherer, daher ist die Standardeinstellung „false“.

Ähnliche Punkte: Zusätzlich zur Verwendung des Standard-Caching-Mechanismus des Systems kann der Second-Level-Cache von Hibernate und Mybatis das Cache-Verhalten vollständig außer Kraft setzen, indem Sie Ihren eigenen Cache implementieren oder Adapter für andere Caching-Lösungen von Drittanbietern erstellen.

Unterschied: Die Cache-Konfiguration der zweiten Ebene von Hibernate wird detailliert in der von SessionFactory generierten Konfigurationsdatei konfiguriert, und dann wird der Cache-Typ in der spezifischen Tabellen-Objekt-Zuordnung konfiguriert.

Die sekundäre Cache-Konfiguration von MyBatis wird in jeder spezifischen Tabellen-Objekt-Zuordnung detailliert konfiguriert, sodass unterschiedliche Caching-Mechanismen für verschiedene Tabellen angepasst werden können. Und Mybatis kann über Cache-ref dieselbe Cache-Konfiguration und Instanz im Namespace teilen.

Vergleich zwischen den beiden: Da Hibernate über einen guten Verwaltungsmechanismus für Abfrageobjekte verfügt, müssen sich Benutzer nicht um SQL kümmern. Wenn bei der Verwendung des Second-Level-Cache fehlerhafte Daten auftreten, meldet das System daher einen Fehler und fordert Sie dazu auf.

In diesem Zusammenhang muss MyBatis bei der Verwendung des Second-Level-Cache besonders vorsichtig sein. Wenn Sie den Umfang des Datenaktualisierungsvorgangs nicht vollständig bestimmen können, vermeiden Sie die blinde Verwendung des Caches. Andernfalls birgt das Auftauchen schmutziger Daten große versteckte Gefahren für den normalen Betrieb des Systems.

Weitere technische Artikel zum Thema Java finden Sie in der Spalte Java-Entwicklungs-Tutorials.

Das obige ist der detaillierte Inhalt vonDer Unterschied zwischen Mybatis und Winterschlaf. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!