DepartamentoMdFactory

A ferramentaria local do Departamento já foi construída na sequência Novo Módulo — existe, mas está vazia, sem nenhuma ferramenta. Agora, na fase CRUD READ, ela ganha a primeira ferramenta: o método proModel() que fabrica o DepartamentoProdutoModel e guarda pra reusar. Sétimo passo da sequência CRUD READ — primeiro arquivo EDITADO.

Nota: quando a ferramentaria foi criada na sequência Novo Módulo, ela tinha só o construtor e o getManager. Nenhuma ferramenta. Aqui a gente adiciona o proModel() com lazy initialization. Em sequências futuras (quando aparecerem novas entidades no módulo), a ferramentaria vai ganhar mais métodos — um por entidade.

CÓDIGO COMPLETO

package br.xt.app.departamento;

import br.jasap.core.AppManager;
import br.xt.app.departamento.produto.DepartamentoProdutoModel;

public class DepartamentoMdFactory {

    protected AppManager manager = null;

    public DepartamentoMdFactory() {
    }

    public DepartamentoMdFactory(AppManager manager) {
        this.manager = manager;
    }

    public AppManager getManager() {
        return manager;
    }

    private DepartamentoProdutoModel proModel = null;
    public DepartamentoProdutoModel proModel() {
        if (proModel == null) proModel = new DepartamentoProdutoModel(manager);
        return proModel;
    }

}

Mudanças nesta fase: apenas os blocos destacados em verde (o import do Model, o atributo proModel e o método proModel()). O resto do arquivo já existia desde a sequência Novo Módulo.

Por que lazy initialization?

O Model só é criado quando realmente precisa. Se o agente passar pelo setor de listagem, vai precisar do ProdutoModel — aí a ferramentaria fabrica. Se o agente passar por algum setor que não precise, o ProdutoModel nem é fabricado nesse request.

Depois de fabricado, a mesma instância é guardada na prateleira da ferramentaria (o atributo proModel) e reusada nas chamadas seguintes do mesmo request. Uma só ferramenta, reusada várias vezes.

Quando o request termina, a ferramentaria inteira é descartada (junto com a Action, junto com a ferramenta). O próximo request cria uma ferramentaria nova, que vai fabricar seu próprio ProdutoModel na primeira chamada.

Por que passar o manager pro construtor do Model?

Porque o Model vai precisar do cartão temporário pra falar com o banco — lembra do episódio do getManager()? O cartão passa de mão em mão: da Action pro getFactory, da ferramentaria central pra ferramentaria local, e aqui da ferramentaria local pro Model via new DepartamentoProdutoModel(manager).

O construtor do Model chama super(manager), que passa pro construtor do DAO, que faz setManager + setDataBase. Resultado: quando o setor de listagem chamar proModel().daoList(...), o Model (com tudo herdado do DAO) tem o cartão necessário pra rodar a query no banco.

O que acontece quando outra entidade for adicionada?

Se no futuro o módulo Departamento ganhar uma entidade "Pessoa", por exemplo, a ferramentaria ganha mais um método análogo:

private DepartamentoPessoaModel pesModel = null;
public DepartamentoPessoaModel pesModel() {
    if (pesModel == null) pesModel = new DepartamentoPessoaModel(manager);
    return pesModel;
}

Cada entidade do módulo tem SEU próprio método na ferramentaria, com sua própria prateleira (pesModel, proModel, etc.). O padrão repete.

Parte já existente (da sequência Novo Módulo)

Quando a sequência Novo Módulo terminou, a ferramentaria tinha o esqueleto: o campo manager protegido, um construtor vazio, um construtor que recebe o AppManager, e um getManager(). Nenhuma ferramenta ainda — só o prédio da oficina pronto.

DepartamentoMdFactory editar arquivo

Parte já existente (da sequência Novo Módulo)

Partes adicionadas nesta fase CRUD READ