Encapsulamento

ROFFLE LOLZOR BONUS POINTS A++++ WOULD DO BUSINESS AGAIN!!!!!!!!!111 pra essa camiseta do Spinal Tap

This message was edited 1 time. Last update was at 01/03/2005 17:59:59

cv wrote:Acho que eu nunca vi uma consulta que retorna mais de um objeto diferente, e esses objetos nao tem relacao nenhuma... ja vi umas queries que retornam um monte de itens, de imagens a blocos de texto, mas todos os itens sao... errr, uhhm, filhos da classe Item

Eu já, quer um bom exemplo?

Dada a seguinte query "me retorne os últimos registros que o usuario alterou", ela não retorna os Rastros do usuario, mas sim os DO em questão.

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4641 Offline

O louds é foda

Mas num caso desses o SGBD iria fazer um full scan em todas as tabelas @.@

Não seria uma solução mais apropriada fazer uma tabela de logging, muito bem representável por um objeto?

E considerando a situação que você apresentou, como seria adequado representar este comportamento dentro do sistema?

This message was edited 1 time. Last update was at 01/03/2005 20:11:56

*Entrando na discussão...

Eu faria um log com os ids alterados. Depois recuperaria eles e iria em cada lugar pegar eles..

Só pra não passar em branco, eu tb uso o mesmo modelo de Bean do Fabio : cada qual herda do Master o "script de CRUD" o qual retornado, eu pego uma SessionFactory e passo pra ela executar.... meio doido, mas funciona

Hnum, To usando tudo isso com Swing tah, e isso me deixa livre pra fazer uma interface pra apresentar o bean bunitinho na tela

Mas to gostando da discussão...

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4641 Offline

brlima, aconselho a ler o segundo artigo indicado pelo AllMighty. O treco é bom

Morte ao MVC!
*facilmente convertido*

LIPE wrote:Morte ao MVC!
*facilmente convertido*

Qual é o slogan agora?

LIPE wrote:O louds é foda

Mas num caso desses o SGBD iria fazer um full scan em todas as tabelas @.@

Não seria uma solução mais apropriada fazer uma tabela de logging, muito bem representável por um objeto?

E considerando a situação que você apresentou, como seria adequado representar este comportamento dentro do sistema?

Eu já implementei auditoria de 2 formas diferentes, cada qual tinha suas exigencias.

Uma foi usando shadow-tables, era bem facil gerar os dados de auditoria mas era uma saco usar essa informação. A outra foi usando uma tabela só com um campo clob com os valores em pares chave-valor, usa 1 tonelada de disco, mas fica mais facil de pesquisar e implementar usando interceptor do Hibernate foi assustadoramente facil.

Enfim, quanto a query, em ambos os casos os DAOs reconstruiam os DO a partir das informações recuperadas, no final das contas retornavam coleções de objetos heterogêneos mesmo. Existia um AutoriaDao que tinha esses métodos de pesquisa. Eu gosto de criar DAOs por casos de uso e não por DO que são partícipes.

E não tem full-table scan não lipe, vale lembrar que o modelo de dados e o modelo dos objetos de dominio não precisam ser parecidos ou ter coisas equivalentes, basta saber ir de um pro outro.

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4641 Offline

Então louds, o "objetivo" aqui seria não usar DAOs hehe mas sem um objeto intermediário aos dois Objetos não relacionados fica difícil.

LIPE wrote:Então louds, o "objetivo" aqui seria não usar DAOs hehe mas sem um objeto intermediário aos dois Objetos não relacionados fica difícil.

Por isso eu nao gosto muito de mapear 1 pra 1, uma tabela pra um objeto, nem sempre isso faz sentido com a real necessidade do sistema. Esse exemplo que o Louds deu é um classico onde teu objeto nao tem nada haver com as tabelas do banco.
Acredito que o dominio do objetos deve ficar independete disso, satisfazendo a tua necessidade para as regras de negocio do sistema e o DAO que se vire pra retornar isso coerentemente.

]['s

Um bom exemplo disso é se você estiver trabalhando com OLAP ou com alguma forma de estatística, teu dominio muito provavelmente vai ter objetos que são agrupamentos de registros do banco.

A alternativa satisfatoria pro DAO, é ORM no estilo do Hibernate usando xdocklet ou annotations, uma pena apenas que ele te obriga a ter getters/setters.

Uma idéia que eu achei muito legal foi uma do Charles Miller de usar IoC para as pesquisas que o teu objeto precisa.

louds wrote:Uma idéia que eu achei muito legal foi uma do Charles Miller de usar IoC para as pesquisas que o teu objeto precisa.

Tem algum artigo sobre louds?

]['s

fabgp2001, que tal o blog dele, de onde li sobre isso?

http://fishbowl.pastiche.org/2004/04/04/cut_with_the_grain

E o que fazer com a coleção heterogênea de objetos? Se eles não implementarem ao menos uma interface em comum, o máximo de informação que podem dar é um toString()? Tem alguma mágica de reflexão?

JavaGuru Membro desde: 31/01/2003 10:21:32 Mensagens: 255 Offline

QUANTO A TRANSAÇÕES... sei que é uma discução um tanto quanto antiga, mas achei o assunto legal e gostaria de compartilhar uma solução...

public ActionForward gravar(ActionMapping mapping, ActionForm form,
        HttpServletRequest request, HttpServletResponse response) throws Exception {
    
    DynaActionForm atividadeForm = (DynaActionForm)form;
    Atividade      atividade     = null;
    
    SystemUserSession   systemUserSession   = new SystemUserSession(request);
    BusinessTransaction businessTransaction = getBusinessTransactionFactory().createNewBusinessTransaction((SystemUser)systemUserSession.getModel());
    
    try {
        businessTransaction.start();

AtividadeBusiness atividadeBusiness = new AtividadeBusiness(businessTransaction);
        
        atividade = (Atividade)atividadeBusiness.newEntityInstance(
                ((Long)atividadeForm.get("idAtividade")).longValue()
        );
        BeanUtils.copyProperties(atividade, atividadeForm);

try {
            businessTransaction.beginTransactionalBlock();

atividadeBusiness.save(atividade);
            
            businessTransaction.commitTransactionalBlock();
        } catch (BusinessTransactionException bte) {
            businessTransaction.rollbackTransactionalBlock();

setAlertMessage(request, be.getMessage());
        }           
    } finally {
        businessTransaction.finish();
    }
    
    atividadeForm.initialize(mapping);
    
    return mapping.findForward("_FormAtividade");        
}

Nessa solução que implementei na arquitetura que desenvolvi para fabrica de software que trabalho, criei uma classe responsavel por controlar o escopo (start/finish) e as ações (begin/commit/rollback) das trasações de negócio do sistema.

O fluxo é o seguinte...

1. start() - cria uma sessão SessionFactory.
2. Vários business-objects podem ser instanciados passando a instância "startada" de businessTransaction e manipulados.
3. beginTransactionalBlock() - inicia uma transação do Hibernate (session.beginTransaction()).
(save/remove/get/anyMethod).
5. businessTransaction.commitTransactionalBlock() ou businessTransaction.rollbackTransactionalBlock() - comita ou descarta a trasação do Hibernate.
6. businessTransaction.finish() - encerra a sessão do Hibernate.

Obviamente que existem outras classes e interfaces envolvidas na parada, mas o conceito é esse.

Da maneira como estruturei essa arquitetura, fica bastante fácil se amanhã ou depois eu não quiser mais utilizar o Hibernate e passar a usar um outro mecanismo de persistencia, porque toda a estrutura está baseada em interfaces.

Bom espero que ajude... espliquei bem por cima, como disse, tem várias classes e interfaces envolvidas, mas acho que deu para enternder o conceito, né?

Sei que ainda tem várias coisas para serem melhoradas e estou trabalhando todos os dias para fazer isso...

...sugestões são bem vindas...

Abraço!

AllMighty wrote:E o que fazer com a coleção heterogênea de objetos? Se eles não implementarem ao menos uma interface em comum, o máximo de informação que podem dar é um toString()? Tem alguma mágica de reflexão?

No meu caso eu tinha 1 factory de helpers que providenciavam a view e outras colaborações.

Notícias, artigos e o maior fórum brasileiro sobre Java