DepartamentoProdutoDAO novo arquivo

package br.xt.app.departamento.produto;

import br.jasap.core.AppManager;
import br.jasap.dao.Query;
import br.jasap.util.JasapList;
import br.xt.AppsRootDAO;

public class DepartamentoProdutoDAO extends AppsRootDAO {

    public DepartamentoProdutoDAO() {
    }

    public DepartamentoProdutoDAO(AppManager manager) {
        setManager(manager);
        setDataBase(manager.getDataBase());
    }

    public void daoList(JasapList list) throws Exception {
        StringBuilder sql = new StringBuilder();
        sql.append("select a.* from " + DepartamentoProdutoBean.TABLE + " a <orderby>");
    
        Query query = getDataBase().getQuery(sql.toString());
        select().executeList(query, list);
    
        while (query.next()) {
            DepartamentoProdutoBean bean = new DepartamentoProdutoBean();
            query.populateBean(bean);
            list.getList().add(bean);
        }
        query.release();
    }

}

O DAO herda em dois níveis:

JasapDAO (Jasap) → AppsRootDAO (projeto) → DepartamentoProdutoDAO

Quando o DAO chama select().executeList(query, list), o select() vem do JasapDAO. O DAO da entidade NÃO implementa nada de SQL básico — herda tudo.

O Bean e o WBean não declaram construtores — o Java cria um vazio automaticamente. Funciona porque são só objetos de dados sem dependências.

O DAO precisa de dois construtores explícitos:

Corrente de criação: MdFactory → Model → super(manager) → DAO configurado com conexão ao banco.

Qualquer chamada de banco pode lançar SQLException (conexão caiu, query inválida, FK quebrada, etc.). O DAO PODERIA capturar com try/catch — mas não é o lugar certo de tratar.

O throws Exception deixa a exceção SUBIR pelo código. Quem captura no fim é um filtro global do framework (ErrorFilter), que registra o erro e mostra uma tela amigável pro usuário.

Vantagem: o DAO fica focado SÓ em falar com o banco. Tratamento de erro é responsabilidade de outra camada.

Em Java, String é imutável — cada concatenação com + cria um objeto novo. Pra montar SQL grande com várias partes, isso vira desperdício de memória.

StringBuilder é uma classe que permite ir adicionando texto SEM criar objeto novo a cada passo. No fim, toString() devolve a string final.

No daoList a montagem é simples (basicamente um append), mas a convenção do projeto é usar StringBuilder sempre que monta SQL — porque em DAOs com filtros condicionais, vão aparecer vários append consecutivos.

Áudio dedicado: tem um áudio só sobre StringBuilder no card Fundamentos Java do estudo, explicando em profundidade por que String é imutável, quando usar StringBuilder vs StringBuffer, e os ganhos de performance reais.

a é um apelido (alias) da tabela. Em SQL, todo apelido depois do nome da tabela serve pra referenciar colunas qualificadas, ex: a.nome_produto.

No daoList aparece em duas linhas:

• select a.* from departamento.produto a — pega todas as colunas da tabela apelidada de a

Aqui parece exagero (a tabela é só uma), mas a convenção do projeto é SEMPRE usar alias. Quando o DAO precisar de JOIN com outras tabelas, cada uma vai ter seu alias (a, b, c), e as referências de coluna ficam claras.

<orderby> é um placeholder que o Jasap reconhece e substitui por uma cláusula ORDER BY real na hora de executar a query.

A configuração de ordem mora na ListView (a tela de listagem). Quando o usuário clica no cabeçalho de uma coluna, a ListView atualiza a ordem desejada e o DAO recebe via JasapList. O Jasap então pega essa ordem e injeta no lugar do <orderby> — algo como:

select a.* from departamento.produto a ORDER BY a.nome_produto ASC

O DAO não precisa saber qual coluna nem direção — só deixa o placeholder e o framework cuida.

O método select() vem do JasapDAO e devolve um objeto helper de SELECT. O executeList(query, list) faz três coisas:

1. Substitui o placeholder <orderby> pela ordem definida no JasapList
2. Aplica paginação automática (LIMIT/OFFSET) com base na página atual da listagem
3. Executa a query no banco e prepara o cursor pra leitura

Depois disso, o DAO pode iterar com while (query.next()) pra ler linha por linha.

O populateBean usa reflection (uma técnica do Java) pra olhar as colunas que vieram do banco e encontrar o setter correspondente em cada uma.

Fluxo:

1. Olha a primeira coluna do resultado: id_produto
2. Procura no Bean um método chamado setId_produto
3. Achou — invoca passando o valor que veio do banco
4. Repete pra cada coluna

Por isso a nomenclatura JavaBean é OBRIGATÓRIA: se o setter se chamasse gravarId em vez de setId_produto, o reflection não acharia e o campo ficaria null.

Áudio dedicado: tem um áudio só sobre Reflection em Java no card Fundamentos Java do estudo, mostrando como o Java consegue olhar a estrutura de uma classe em runtime e invocar métodos pelo nome.

Cada Query abre recursos no banco: cursor, ResultSet, conexão emprestada do pool. Esses recursos precisam ser DEVOLVIDOS quando a leitura termina.

Sem query.release(), os recursos ficam pendurados. Com o tempo, o pool de conexões esgota — todo mundo tentando conectar e ninguém consegue. O sistema trava.

Por que não tem try/finally? Porque o throws Exception deixa a exceção subir pro filtro global, e em produção o framework garante que conexões órfãs sejam fechadas no fim do request via DataBaseFilter. Mas o release() explícito é a boa prática — libera ASSIM QUE o cursor termina, sem esperar o fim do request.