DepartamentoProdutoModel novo arquivo

0:00 / 0:00

O Model é uma camada fina em cima do DAO. Fica entre o formulário e o DAO — é onde as regras de negócio vão morar conforme o módulo crescer. Quarto arquivo da sequência CRUD READ — pequeno e quase vazio, mas cria o ponto de entrada pra qualquer regra futura.

Nota: nesta fase CRUD READ o Model tem só o construtor. Os métodos insert, update e delete vão chegar conforme as sequências CREATE, UPDATE e DELETE forem acontecendo — cada uma adiciona o método correspondente aqui. Como o Model estende o DAO, ele já herda daoList, então o código do setor de listagem consegue acessar o daoList usando a referência do Model.

CÓDIGO COMPLETO 
package br.xt.app.departamento.produto;

import br.jasap.core.AppManager;

public class DepartamentoProdutoModel extends DepartamentoProdutoDAO {

    public DepartamentoProdutoModel(AppManager manager) {
        super(manager);
    }

}
Por que o Model está quase vazio?

Porque nesta fase CRUD READ não tem regra de negócio nenhuma pra rodar. O agente só precisa BUSCAR produtos no almoxarifado — e pra isso o DAO já basta.

Em módulos mais complexos, o Model é onde entram validações, cálculos e propagações. Por exemplo, na sequência CREATE, um insert(bean) no Model poderia:

  • Montar um campo qs_produto (quick search) com o nome normalizado antes de gravar
  • Validar combinações inválidas entre campos
  • Atualizar contadores em outras tabelas

A gente cria o Model AGORA pra deixar a camada pronta. Quando a regra aparecer, ela entra aqui sem precisar mexer no formulário nem no DAO.

Por que o Model estende o DAO?

Porque o formulário e a listagem vão acessar tudo pelo Model — getFactory().departamento().proModel().daoList(...). Se o Model não estendesse o DAO, seria preciso criar duas instâncias separadas (uma do DAO, uma do Model) e gerenciar as duas.

Estendendo, o Model herda tudo do DAO (daoList agora, futuramente daoSingle, daoInsert, daoUpdate, daoDelete) e ainda pode SOBRESCREVER se precisar adicionar regra antes de chamar o método do DAO.

A cadeia completa de herança fica: JasapDAO → AppsRootDAO → DepartamentoProdutoDAO → DepartamentoProdutoModel — 4 níveis.

Quem chama o construtor do Model?

A MdFactory do Departamento — que é a ferramentaria local do módulo. Na primeira vez que alguém pede um ProdutoModel, a ferramentaria cria via new DepartamentoProdutoModel(manager), passando o cartão temporário. Depois guarda na prateleira pra reusar no mesmo pedido.

A corrente fica assim:

  1. Setor de listagem chama getFactory().departamento().proModel()
  2. MdFactory cria o Model passando o AppManager
  3. Construtor do Model chama super(manager)
  4. Chega no construtor do DAO, que faz setManager + setDataBase
  5. Pronto — o Model (com tudo do DAO herdado) está configurado pra acessar o banco

public class DepartamentoProdutoModel extends DepartamentoProdutoDAO

ElementoO que significa
DepartamentoProdutoModelConvenção do projeto: prefixo do módulo + entidade + Model
extends DepartamentoProdutoDAOHerda todos os métodos do DAO. Nesta fase READ, herda daoList. Nas próximas sequências, vai herdar também daoSingle, daoInsert, daoUpdate, daoDelete conforme forem adicionados no DAO

DepartamentoProdutoModel(AppManager manager)

Único método do Model nesta fase. Recebe o cartão temporário (AppManager) e passa direto pro construtor do DAO via super(manager). O construtor do DAO configura setManager e setDataBase — a conexão com o banco fica pronta pra uso.