Fonctionnalité de requête un à un de MyBatis

Le recherche un à un signifie que nous devons rechercher des données d'autres tables lors de la recherche de données d'une table.

　Besoin

　　　　D'abord, parlons d'un petit besoin de recherche un à un : supposons que nous devons rechercher les informations d'une commande spécifique et rechercher également les informations utilisateur créant cette commande. Le modèle de table est le suivant (

　ResultType

　　Écriture de l'expression SQL

　　　　Tout d'abord, nous devons analyser nos besoins.1. Nous devons déterminer quels deux tableaux sont impliqués dans ce besoin, et quel est le tableau principal et le tableau de liaison. Comment déterminer cela, encore une fois, c'est le besoin - notre besoin est de vérifier les utilisateurs créant une commande lors de la recherche des commandes. Alors, c'est très clair. Notre tableau principal est le tableau des commandes (orders). Et notre tableau de liaison est le tableau des utilisateurs (user).

　　　　Là, nous pouvons écrire la requête SQL suivante :

select * from orders

　　　　Là, nous devons envisager ce problème : devrions-nous utiliser une jointure interne ou externe lors de la recherche par jointure ? Pour ceux qui ne comprennent pas la différence entre les jointures internes et externes, je vais d'abord expliquer simplement ici, et je vais écrire un blog plus détaillé à l'avenir : une jointure interne affiche uniquement les conditions satisfaites. Les jointures externes se divisent en jointures externes gauche et droite : une jointure externe gauche affiche toutes les données de gauche ajoutées aux données communes de droite ; une jointure externe droite affiche toutes les données de droite et les données communes de gauche et de droite.

　　Notre besoin est de lier les utilisateurs via les commandes, et comme il y a une clé étrangère (userId) dans la table orders. Lors de la recherche des données de la table utilisateur via la clé étrangère, userId est la clé principale de la table utilisateur. À ce moment-là, seul un utilisateur peut être trouvé, et ce enregistrement ne modifiera pas le résultat principal de notre recherche. Par conséquent, nous choisissons la recherche par jointure interne. À ce moment-là, notre requête SQL est la suivante :

　select * from orders, user where orders.user_id = user.id

　　　　Après la recherche, les résultats apparaissent comme suit :

　　　　Là, le problème se pose, nous avons découvert que, à ce moment-là, deux ids sont apparus, ce qui pourrait entraîner des problèmes lors de l'encapsulation de nos données en objet lors de l'output. De plus, la colonne User_id est en double avec nos données d'id utilisateur. Nous devons modifier notre sql. Comment le faire ?

　　　　Parce que nos données principales doivent être consultées intégralement, tandis que pour la table des utilisateurs, nous ne avons besoin que des informations username, sex, adress (c'est une hypothèse, il n'est pas nécessaire de se soucier de ce que nous avons besoin). Alors, nous devons manuellement spécifier les champs de requête de notre requête SQL:　　　　

SELECT 
 SELECT*orders.
 ,
 USER.username,
 USER.sex, 
USER.address
 FROM
 orders, 
USER

　　　　WHERE orders.user_id = user.id

　　 Toutes ces opérations ci-dessus sont basées sur l'outil de liaison SQL, lorsque nous pouvons afficher la base de données nécessaire, notre requête SQL est déterminée. À ce moment-là, nous devons commencer à passer à l'étape suivante :

　　　　Créer le pojo

　　　　Nous devons encapsuler les résultats de la requête dans les objets correspondants à l'aide du cadre MyBatis. Alors, la question se pose, qui recevra ces données ? Si nous devons mapper le résultat de la requête SQL ci-dessus dans un pojo, le pojo doit inclure tous les noms de colonnes de la requête. Mais que ce soit la classe Orders d'origine ou la classe User, elles ne peuvent pas mapper tous les champs. Dans ce cas, nous avons une solution très simple : écrire une classe spéciale selon les champs retournés, qui contient tous les résultats de la requête, puis faire que cette classe reçoive le jeu de résultats retourné.

　　　　Il y a une petite astuce à ce moment-là, dans notre nouveau pojo, nous n'avons pas besoin d'écrire tous les champs, nous pouvons faire hériter notre nouveau pojo d'une classe qui contient plus de champs du jeu de résultats, puis écrire les autres données nécessaires dans ce sous-classe.

　　　　mapper.xml

　　　　Après avoir créé le pojo, nous devons créer notre fichier de mapping selon les normes et écrire les méthodes correspondantes dans l'interface :

　Interface dans mapper.java :

　　　　ResultMap

　　Requête SQL, resultMap et resuleMap sont implémentés de la même manière, nous passons directement à l'aspect suivant.

　　　　L'idée de mapping utilisée par resultMap

　　　　Nous savons que lorsque nous utilisons des pojos, nous pouvons encapsuler certains données dans les attributs des objets pojo, qui peuvent être de types simples ou d'autres pojos. À ce moment-là, nous pouvons procéder ainsi :

　　　 Ajouter l'attribut user à la classe Orders

　　mapper.xml

　　　　Lorsque nous utilisons la méthode resultMap pour mapper le jeu de résultats, nous devons effectuer deux opérations : d'une part, définir resultMap et configurer les attributs de l'objet correspondant à chaque colonne du jeu de résultats trouvé. Cela peut être un peu complexe mais pas difficile. D'autre part, définir notre statement.

　　　resultMap

　　　　resultMap实现的基本思路我们刚才已经说了。而且也在orders的pojo类中增加了相应的属性了。接下来，就是写一个resultMap，将整个查询的结果映射到Orders中在这里面，首先是order订单的映射。就是直接用id 和result标签将两者相互对应即可。然后就是，关联的用户信息的映射，这时候需要用到一个association的标签，将在orders类中的user字段与User类进行映射，然后在其内部还是用id和result标签，将查询的数据和User的属性相映射。

　　　　具体代码如下：　　　

<!-- 订单查询关联用户的resultMap
 将整个查询的结果映射到cn.mybatis.po.Orders中
  -->
 <resultMap type="cn.mybatis.po.Orders" id="OrdersUserResultMap">
  <!-- 配置映射的订单信息 -->
  <!-- id：指定查询列中的唯 一标识，订单信息的中的唯 一标识，如果有多个列组成唯一标识，配置多个id
   column：订单信息的唯 一标识 列
   property：订单信息的唯 一标识 列所映射到Orders中哪个属性
   -->
  <id column="id" property="id"/>
  <result column="user_id" property="userId"/>
  <result column="number" property="number"/>
  <result column="createtime" property="createtime"/>
  <result column="note" property=note/>
  <!-- 配置映射的关联的用户信息 -->
  <!-- association：用于映射关联查询单个对象的信息
  property：要将关联查询的用户信息映射到Orders中哪个属性
   -->
  <association property="user" javaType="cn.mybatis.po.User">
   <!-- id：关联查询用户的唯 一标识
   column：指定唯 一标识用户信息的列
   javaType：映射到user的哪个属性
    -->
   <id column="user_id" property="id"/>
   <result column="username" property="username"/>
   <result column="sex" property="sex"/>
   <result column="address" property="address"/>
  </association>
 </resultMap>

　　　La déclaration

　　　　La déclaration est assez simple, il suffit de changer le mode de mappage du jeu de résultats en resultMap. Ensuite, changez le type de retour en resultMap que nous venons de terminer.

　　mapper.java　　　　

　Les différences entre eux

　　　　Après avoir expliqué les méthodes d'implémentation de la consultation un à un, analysons maintenant leurs différences et leurs avantages et inconvénients.

　　　　Tout d'abord, il faut modifier le pojo, soit en ajoutant une classe pojo, soit en modifiant les champs du pojo. Personnellement, selon le principe d'ouverture et de fermeture du design pattern, je pense que resultType est meilleur que resultMap.

　　　　Ensuite, en termes de simplicité, l'utilisation de resultType est plus simple. À ce niveau, resultType est aussi meilleur que resultMap.

　　　　Cependant, resultMap peut réaliser le chargement différé, resultType ne peut pas réaliser le chargement différé. À cet égard, resultType n'est pas aussi bon que resultMap.

　　　　Donc : je recommande vivement d'utiliser resultType si vous n'avez pas de demandes spéciales pour les résultats de la consultation.

Les fonctionnalités de consultation un à un de mybatis que l'éditeur vous présente ci-dessus, j'espère qu'elles vous seront utiles. Si vous avez des questions, laissez-moi un message, je vous répondrai à temps. Je tiens également à remercier chaleureusement le soutien de la communauté du site Web de tutoriel d'alarme !

Déclaration : Le contenu de cet article est extrait du réseau, la propriété intellectuelle appartient à ses auteurs respectifs, le contenu est contribué et téléchargé par les utilisateurs d'Internet, ce site Web ne détient pas de propriété, n'a pas été traité par l'éditeur humain et n'assume aucune responsabilité juridique. Si vous trouvez du contenu susceptible de violer les droits d'auteur, veuillez envoyer un e-mail à : notice#w3Déclaration : Le contenu de cet article est extrait du réseau, la propriété intellectuelle appartient à ses auteurs respectifs, le contenu est contribué et téléchargé par les utilisateurs d'Internet, ce site Web ne détient pas de propriété, n'a pas été traité par l'éditeur humain et n'assume aucune responsabilité juridique. Si vous trouvez du contenu susceptible de violer les droits d'auteur, veuillez envoyer un e-mail à : notice#w