La différence entre mybatis et hiberner

Les deux combinaisons de frameworks principales que nous utilisons dans le développement Java sont SSM, Spring, SpringMVC, MyBatis et SSH, Struts2, Spring et Hibernate. Aujourd'hui, nous allons d'abord examiner les différences entre les deux frameworks de bases de données.

Premier aspect : Comparaison de la vitesse de développement

En termes de vitesse de développement, il est plus difficile de véritablement maîtriser Hibernate que Mybatis quelques. Le framework Mybatis est relativement simple et facile à utiliser, mais il est également relativement rudimentaire. Personnellement, je pense que pour bien utiliser Mybatis, il faut d'abord comprendre Hibernate. (Apprentissage recommandé : Tutoriel vidéo Java)

En comparant la vitesse de développement des deux, non seulement les caractéristiques et les performances des deux doivent être prises en compte, mais aussi laquelle doit être considérée en fonction de Les besoins du projet sont plus adaptés au développement de projets. Par exemple, il n'y a pratiquement pas de requêtes complexes utilisées dans un projet, juste de simples ajouts, suppressions, modifications et requêtes. De cette façon, l'efficacité du choix de la mise en veille prolongée est très rapide, car la mise en veille prolongée est plus efficace. Les instructions SQL de base ont été encapsulées et vous n'avez pas du tout besoin d'y aller. L'écriture d'instructions SQL permet de gagner beaucoup de temps, mais pour un grand projet, il existe de nombreuses instructions complexes, donc choisir hibernate n'est pas un bon choix. va beaucoup accélérer et la gestion des déclarations est également plus pratique .

Deuxième aspect : Comparaison de la charge de travail de développement

Hibernate et MyBatis disposent tous deux d'outils de génération de code correspondants. Des méthodes de couche DAO simples et basiques peuvent être générées. Pour les requêtes avancées, Mybatis nécessite l'écriture manuelle des instructions SQL et ResultMap. Hibernate dispose d'un bon mécanisme de mappage. Les développeurs n'ont pas besoin de se soucier de la génération SQL et du mappage des résultats et peuvent se concentrer davantage sur les processus métier.

Le troisième aspect : l'optimisation SQL

La requête Hibernate interrogera tous les champs de la table, ce qui consommera des performances. Hibernate peut également écrire son propre code SQL pour spécifier les champs qui doivent être interrogés, mais cela détruit la simplicité du développement d'Hibernate. Le SQL de Mybatis est écrit manuellement, les champs de requête peuvent donc être spécifiés selon les besoins.

Le réglage des instructions Hibernate HQL nécessite l'impression du SQL, et le SQL d'Hibernate n'est pas apprécié par de nombreuses personnes car il est trop laid. Le SQL de MyBatis est écrit manuellement par moi-même, il est donc facile à ajuster. Mais Hibernate possède ses propres statistiques de journal. Mybatis lui-même ne dispose pas de statistiques de journalisation et utilise Log4j pour la journalisation.

Aspect 4 : Comparaison de la gestion des objets

Hibernate est une solution complète de mappage objet/relationnel, qui fournit la fonction de gestion de l'état des objets. Les développeurs n'ont plus à s'inquiéter. sur les détails du système de base de données sous-jacent. En d'autres termes, par rapport à la solution de couche de persistance JDBC/SQL courante qui doit gérer les instructions SQL, Hibernate adopte une perspective orientée objet plus naturelle pour conserver les données dans les applications Java.

En d'autres termes, les développeurs utilisant Hibernate doivent toujours se concentrer sur l'état de l'objet et ne pas avoir à considérer l'exécution des instructions SQL. Ces détails sont déjà pris en charge par Hibernate, et seuls les développeurs doivent les comprendre lors du réglage des performances du système. MyBatis ne dispose pas de documentation dans ce domaine et les utilisateurs doivent gérer eux-mêmes les objets en détail.

Le cinquième aspect : le mécanisme de mise en cache

Cache Hibernate

Le cache Hibernate de premier niveau est le cache de session, corrigez l'utilisation du cache de premier niveau Le cache doit bien gérer le cycle de vie de la session. Il est recommandé d'utiliser une session dans une opération d'action. Le cache de premier niveau nécessite une gestion stricte de Session.

Le cache de deuxième niveau Hibernate est un cache de niveau SessionFactory. Le cache de SessionFactory est divisé en cache intégré et cache externe. Le cache intégré stocke les données contenues dans certains attributs de collection de l'objet SessionFactory (données d'éléments de mappage et instructions SQL planifiées, etc.), qui sont en lecture seule pour les applications. Le cache externe stocke une copie des données de la base de données et sa fonction est similaire à celle du cache de premier niveau. En plus d'utiliser la mémoire comme support de stockage, le cache de deuxième niveau peut également utiliser des périphériques de stockage externes tels que des disques durs. Le cache de deuxième niveau est appelé cache au niveau du processus ou cache au niveau SessionFactory. Il peut être partagé par toutes les sessions. Son cycle de vie existe et meurt avec le cycle de vie de SessionFactory.

MyBatis Cache

MyBatis contient une fonctionnalité de mise en cache des requêtes très puissante, qui peut être configurée et personnalisée très facilement. De nombreuses améliorations de l'implémentation du cache dans MyBatis 3 ont été implémentées, le rendant plus puissant et plus facile à configurer.

Par défaut, la mise en cache n'est pas activée. En plus de la mise en cache de session locale, elle peut améliorer la monétisation et est également nécessaire pour gérer les dépendances circulaires. Pour activer la mise en cache L2, vous devez ajouter une ligne à votre fichier de mappage SQL :

C'est littéralement tout. L'effet de cette simple instruction est le suivant :

Toutes les instructions select du fichier d'instructions de mappage seront mises en cache.

Toutes les instructions d'insertion, de mise à jour et de suppression dans le fichier d'instructions mappé videront le cache.

Le cache sera récupéré à l'aide de l'algorithme le moins récemment utilisé (LRU, le moins récemment utilisé).

Selon le calendrier (par exemple, pas d'intervalle de vidage, pas d'intervalle de rafraîchissement), le cache ne sera actualisé dans aucun ordre chronologique.

Le cache stocke 1024 références à la collection de liste ou à l'objet (indépendamment de ce que renvoie la méthode de requête).

Le cache sera considéré comme un cache en lecture/écriture, ce qui signifie que la récupération des objets n'est pas partagée et peut être modifiée en toute sécurité par les appelants sans interférer avec ce que font les autres appelants ou les modifications potentielles.

Toutes ces propriétés peuvent être modifiées via les propriétés de l'élément de cache.

Par exemple :

Cette configuration plus avancée crée un cache FIFO, et s'actualise toutes les 60 secondes, enregistrant 512 références à l'objet ou à la liste résultat, et les objets renvoyés sont considérés comme en lecture seule, donc les modifier entre les appelants dans différents threads peut provoquer des conflits. Les stratégies d'expulsion disponibles sont, la valeur par défaut est LRU :

LRU – Les moins récemment utilisés : supprimez les objets qui n'ont pas été utilisés depuis le plus longtemps.

FIFO – Premier entré, premier sorti : supprimez les objets dans l'ordre dans lequel ils entrent dans le cache.

SOFT – Soft Reference : supprime les objets en fonction de l'état du ramasse-miettes et des règles de référence logicielle.

FAIBLE – Références faibles : supprimez de manière plus agressive les objets en fonction de l'état du ramasse-miettes et des règles de référence faibles.

flushInterval peut être défini sur n'importe quel entier positif et représente une période de temps raisonnable en millisecondes. La valeur par défaut n'est pas définie, c'est-à-dire qu'il n'y a pas d'intervalle d'actualisation et le cache n'est actualisé que lorsque l'instruction est appelée.

la taille (nombre de références) peut être définie sur n'importe quel entier positif, en gardant à l'esprit le nombre d'objets que vous mettez en cache et le nombre de ressources mémoire disponibles dans votre environnement d'exécution. La valeur par défaut est 1024.

L'attribut readOnly peut être défini sur true ou false. Un cache en lecture seule renverra la même instance de l'objet mis en cache à tous les appelants. Ces objets ne peuvent donc pas être modifiés. Cela offre d’importants avantages en termes de performances. Un cache en lecture-écriture renvoie une copie de l'objet mis en cache (via la sérialisation). C'est plus lent, mais plus sûr, donc la valeur par défaut est false.

Points similaires : en plus d'utiliser le mécanisme de mise en cache par défaut du système, le cache de deuxième niveau d'Hibernate et Mybatis peut complètement remplacer le comportement du cache en implémentant votre propre cache ou en créant des adaptateurs pour d'autres solutions de mise en cache tierces.

Différence : la configuration du cache de deuxième niveau d'Hibernate est configurée en détail dans le fichier de configuration généré par SessionFactory, puis le type de cache est configuré dans le mappage table-objet spécifique.

La configuration du cache de deuxième niveau de MyBatis est configurée en détail dans chaque mappage table-objet spécifique, afin que différents mécanismes de mise en cache puissent être personnalisés pour différentes tables. Et Mybatis peut partager la même configuration de cache et la même instance dans l'espace de noms, via Cache-ref.

Comparaison entre les deux : Étant donné qu'Hibernate dispose d'un bon mécanisme de gestion des objets de requête, les utilisateurs n'ont pas besoin de se soucier de SQL. Par conséquent, si des données sales apparaissent lors de l'utilisation du cache de deuxième niveau, le système signalera une erreur et une invite.

À cet égard, MyBatis doit être particulièrement prudent lors de l'utilisation du cache de deuxième niveau. Si vous ne pouvez pas déterminer complètement la portée de l'opération de mise à jour des données, évitez l'utilisation aveugle du cache. Sinon, l’émergence de données sales entraînera de grands dangers cachés pour le fonctionnement normal du système.

Pour plus d'articles techniques liés à Java, veuillez visiter la colonne Tutoriel de développement Java pour apprendre !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!