English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
O que se chama de consulta um-a-um é que, ao consultar dados de uma tabela, precisamos consultar dados de outras tabelas.
Necessidade
Primeiro, vamos falar de uma pequena necessidade de consulta um-a-um: suponhamos que, ao consultar informações de um pedido específico, precisamos consultar informações de usuário correspondente. O modelo de tabela é o seguinte (
ResultType
Escrita de sql
Primeiro, devemos analisar nossa necessidade.1. Precisamos determinar quais duas tabelas envolvem essa necessidade, qual é a tabela principal e qual é a tabela associativa. Como determinar, ainda depende da necessidade - nossa necessidade é que, ao consultar pedidos, também consultemos o usuário que criou o pedido. Então, é muito claro. A nossa tabela principal é a tabela de pedidos (orders). E a nossa tabela associativa é a tabela de usuários (user).
Neste momento, podemos escrever a seguinte sentença SQL:
select * from orders
Neste momento, devemos considerar este problema: devemos usar consulta aninhada ou consulta externa na consulta de associação? Para aqueles que não sabem a diferença entre consulta aninhada e consulta externa, aqui apresento uma breve introdução, e escreverei um blog detalhado mais tarde: a consulta aninhada mostra apenas os que atendem aos critérios. A consulta externa é dividida em consulta externa esquerda e consulta externa direita: a consulta externa esquerda mostra todos os da esquerda mais os iguais da direita; a consulta externa direita mostra todos os da direita e os iguais da esquerda e da direita.
Nossa necessidade é relacionar usuários através de pedidos, e devido a um campo estrangeiro (userId) na tabela orders. Ao consultar os dados da tabela associativa user através do campo estrangeiro, userId é a chave primária da tabela user. Neste momento, apenas uma informação de user pode ser consultada, e este registro não mudará o resultado da consulta principal. Portanto, optamos por consulta aninhada. Neste momento, nossa sentença SQL é a seguinte:
select * from orders, user where orders.user_id = user.id
Após a consulta, o resultado é o seguinte:
Agora, o problema surgiu, percebemos que neste momento apareceram dois ids, o que levará a problemas ao encapsular nossos dados na saída para objetos. Além disso, a coluna User_id é duplicada em relação aos nossos dados de id de usuário. Precisamos modificar nossa sql. Como modificar?
Porque nossos dados da tabela principal precisam ser consultados em sua totalidade, enquanto para a tabela de usuários, precisamos apenas das informações username, sex, adress (aqui é uma hipótese, não é necessário se preocupar com o que precisamos). Portanto, precisamos especificar manualmente os campos de consulta de nossa sentença SQL:
SELECT orders.*, USER.username, USER.sex, USER.address FROM orders, USER WHERE orders.user_id = user.id
Tudo isso é feito na consulta com nossa ferramenta de conexão sql, quando podemos exibir o banco de dados necessário, nossa consulta sql está definida. Neste ponto, devemos começar o próximo passo:
Criar pojo
Precisamos encapsular os resultados da consulta através do framework Mybatis em objetos correspondentes. Então, surge a questão: quem vai receber esses dados encontrados? Se vamos mapear o resultado da consulta sql acima para o pojo, o pojo deve incluir todos os nomes das colunas de consulta. Mas tanto a classe Orders original quanto a classe User não podem mapear todos os campos. Neste caso, temos uma solução simples: escrevermos uma classe específica com base nos campos retornados, que inclua todos os resultados da consulta, e esta classe receberá o conjunto de resultados retornado.
Neste momento, há uma pequena técnica: não precisamos escrever todos os campos no novo pojo, podemos fazer o novo pojo herdar de um classe que contém muitos campos de resultados no conjunto de resultados, e escrever os outros dados necessários neste subclasse.
Após a criação do pojo, precisamos criar nosso arquivo de mapeamento conforme as normas e escrever os métodos correspondentes na interface:
mapper.xml
Interface no mapper.java:
ResultMap
No nível da consulta sql, a implementação de resultType e resuleMap é a mesma, então pulemos isso.
Pensamento de mapeamento resultMap
Sabemos que, ao usar pojo, podemos encapsular alguns dados nos atributos do objeto pojo, que podem ser tipos simples ou outro pojo. Neste caso, podemos fazer assim:
Usamos resultMap para mapear as informações de pedidos na consulta de resultados para o objeto Orders, adicionamos o atributo User na classe orders, mapeamos as informações de usuário encontradas na consulta de associação para a propriedade user do objeto orders.
Adicionar o atributo user na classe Orders
mapper.xml
Quando usamos o método resultMap para mapear o conjunto de resultados, precisamos realizar duas operações: uma é definir o resultMap, configurar as propriedades dos objetos correspondentes a cada coluna encontrada no conjunto de resultados. Isso é um pouco complicado, mas não difícil. A outra é definir nosso 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>
statement
statement é muito simples, é apenas alterar o modo de mapeamento do conjunto de resultados para resultMap. Em seguida, configure o tipo de retorno para o resultMap recém-criado.
mapper.java
Diferenças entre os dois
Com a implementação da consulta um-a-um concluída, vamos analisar suas diferenças e vantagens e desvantagens.
Primeiro, ambos precisam modificar o pojo, um é adicionar uma classe pojo e o outro é modificar os campos do pojo. Pessoalmente, acho que, de acordo com o princípio de abertura e fechamento do padrão de design, resultType é melhor do que resultMap.
Em termos de simplicidade, a implementação de resultType é mais simples. Neste sentido, resultType também é melhor do que resultMap.
No entanto, resultMap pode implementar carregamento diferido, resultType não pode implementar carregamento diferido. Em termos disso, resultType não é tão bom quanto resultMap.
Portanto: recomendo que, se não houver requisitos especiais para resultados de consulta, use resultType.
O que foi mencionado acima é a função de consulta um-a-um do mybatis apresentada pelo editor, esperando que ajude a todos. Se você tiver alguma dúvida, por favor, deixe um comentário, o editor responderá a tempo. Agradecemos também o apoio ao site Tutorial de Grito!
Declaração: O conteúdo deste artigo é extraído da Internet, pertencente ao respectivo detentor dos direitos autorais, contribuído e carregado voluntariamente pelos usuários da Internet. Este site não possui direitos de propriedade, não foi editado manualmente e não assume responsabilidades legais relacionadas. Se você encontrar conteúdo suspeito de violação de direitos autorais, por favor, envie um e-mail para: notice#oldtoolbag.com (ao enviar e-mail, substitua # por @ para denunciar e forneça provas relevantes. Caso seja confirmado, o site deletará imediatamente o conteúdo suspeito de violação de direitos autorais.)