Premature Encapsulation is the Root of All Evil

Programação Arquitetura
#21

Nao estou testando o framework X, estou testando se fiz o mapeamento correto. Pois pode acontecer, depois que o sistema estiver em producao eu precisar alterar qualquer coisa no meu codigo e tudo funcionar perfeitamente, a regra aplicada corretamente, a integridade do estado dos objetos mantida, todo ciclo de vida devidamente mantido, mas cinco minutos depois que eu gero a versao para o cliente ele me liga dizendo que a tela tal parou de funcionar. Aí, depois de ver o log de erro eu descubro que esqueci de alterar o mapeamento. Ou entao, pior ainda, esqueci de alterar o modelo de dados para a alteracao que eu fiz.

Se eu tivesse um banco de testes, utilizando testes unitarios eu teria reduzido bastante a probabilidade disso acontecer.

DBUnit é para testar o banco, se o esquema esta correto, se sua classe esta sendo mapeada corretamento para o banco, nao outra coisa. Tudo isso que voce disse tem que ser feito, mas alem disso o esquema e o mapeamento TÊM que ser testados.

#22

[quote=YvGa]
Tudo isso que voce disse tem que ser feito, mas alem disso o esquema e o mapeamento TÊM que ser testados.[/quote]

O ponto é que não precisam ser testados a todo o momento. Existem vários niveis para os testes. Esse tipo de coisas é testada em teste de integração que rodam pouco frequentemente em relação aos teste com foco em desenvolver features.

#23

Concordo com o sérgio, testar a persistência tem a sua hora e lugar. Testá-lo toda hora deixa o processo de build extremamente lento em projetos maiores.

#24

[quote=sergiotaborda]
O ponto é que não precisam ser testados a todo o momento. Existem vários niveis para os testes. Esse tipo de coisas é testada em teste de integração que rodam pouco frequentemente em relação aos teste com foco em desenvolver features.[/quote]

Então vc tem um teste de integração com o banco de dados e trata os erros provenientes da disponibilidade do servidor ou apenas confia?

De qualquer forma, sou a favor de usar ferramentas como o dbunit. Pela experiência que tenho, quanto mais distanciarmos o desenvolvimento do ambiente real maiores serão os problemas na hora da entrega.

#25

Concordo plenamente. Mas eles têm que existir e têm que ser executados toda vez que ha uma alteracao no esquema do banco ou no mapeamento.

Claro que se voce executar esses testes junto com os testes do dominio vai acabar mais cedo ou mais tarde inviabilizando os testes.

#26

Rubem, deixe eu tomar seus exemplos emprestado para opinar neste tópico! :wink:

[quote=Rubem Azenha]Eu uso DAO para não ter código de Hibernate/JPA/ETC espalhado pela aplicação inteira.

prefiro ter um DAO e fazer

findByXPTO

do que

q = em.createQuery("asdadasdasda");
q.setParameter(112321,1231231);
q.setParameter(112321,1231231);
q.setParameter(112321,1231231);
q.setParameter(112321,1231231);
q.getResultList();

[/quote]

IMHO, uma opção para tirar o DAO fora e ainda ter um codigo bacana seria, por exemplo:

FindByXPTO find = new FindByXPTO(session);
List<XPTO> list = find.list();

O exemplo é simples, mas acredito que seja suficiente pra demonstrar outras maneiras de organiar o codigo e mantê-lo legível. Claro que o mais comum é usar um DAO, mas dependendo do tamanho do projeto prefiro evitar a criação de uma interface para o DAO e sua respectiva implementação.

Eu já venho evitando DAO’s em meus projetos pessoais. O mais comum é eu usar repositórios para abstrair o local onde guardo as entidades, no entanto, não são todos os projetos que necessitam de idéias como DDD e seu famoso repositório.

O framework apache click, um framework ‘component-based’, tem alguns exemplos onde as ações CRUD para persistência já está embutida nos proprios componentes de UI. Outro framework interessante é o Databinder, que também incorporou chamadas de persistências em seus componentes de UI.

A parte difícil, em minha opinião, é que ao abandonar os DAO’s você acaba saindo fora do senso comum. Agora você terá que usar sua criatividade, estudar novos patterns e métodos para abrir mão do DAO e manter o codigo legível.

Segue algumas referências abaixo:
http://svn.apache.org/repos/asf/incubator/click/trunk/examples/click-cayenne/


http://databinder.net/site/show/overview

#27

[quote=Rubem Azenha]Eu uso DAO para não ter código de Hibernate/JPA/ETC espalhado pela aplicação inteira.

prefiro ter um DAO e fazer

findByXPTO

do que

q = em.createQuery("asdadasdasda");
q.setParameter(112321,1231231);
q.setParameter(112321,1231231);
q.setParameter(112321,1231231);
q.setParameter(112321,1231231);
q.getResultList();

[/quote]

Esse tipo de interpretacao que me da medo. O Rubem, apesar de ter interpretado errado o texto (ou eu o fiz), demonstrou que tem experiencia suficiente pra nao fazer dessa forma que ele entendeu.

Mas muita gente que esta lendo esse topico pode ter interpretado do mesmo jeito que ele e vai sair por ai fazendo as coisas como na opcao 2 do Rubem. Mas nao é a isso que o texto se refere. Ou fui eu que nao entendi.

O que tem sido feito é usar interface do repositorio->implementacao do repositorio->interface dao->implementacao de um dao generico->subclasse do dao generico->api do framework de persistencia.

Quando simplesmente interface repositorio->implementacao repositorio->api framework ja resolve.

Eu trabalho numa empresa que nao incentiva boas praticas de programacao e ouco diariamente distorcoes absurdas de padroes. Por isso me arrepiam textos desse tipo.

Esses dias, tentando interpretar um codigo praticamente ilegivel, num metodo com dezenas de linhas e variaveis com nomes sem pé nem cabeca eu perguntei ao autor porque nao poe comentario pelo menos e ele me diz que comentario é anti-pattern. Como ele nao eh meu subordinado, alias o cargo dele eh o mesmo que o meu, só pude dar risada e enfiar o nariz no codigo pra decifrar.

É um tal de separar apresentacao de logica com web service, nao por comentario porque é anti-pattern. dizer que código bem feito nao precisa de teste. Tanto que criei pavor desses textos porque tenho certeza que eles vao cair em maos erradas.

#28