Premature Encapsulation is the Root of All Evil

This message was edited 1 time. Last update was at 16/07/2009 10:42:43

Sendo simplista:
Use um ORM (JPA/TopLink/Hibernate/etc), e implemente todo o acesso aos dados no repository usando o seu ORM.

Pronto falei!!

Eu estava me referindo a Postre e SQLServer como fontes de dados diferentes.

This message was edited 1 time. Last update was at 16/07/2009 11:06:49

ViniGodoy wrote:Eu estava me referindo a Postre e SQLServer como fontes de dados diferentes.

Como eu disse, eu ja precisei fazer essa migracao num sistema relativamente complexo. Foi feito sem traumas, mas gracas ao hibernate, nao gracas aos daos. E claro, eu tinha controle absoluto sobre os esquemas dos bancos.

Se tivesse sido feito diretamente com JDBC o trabalho seria bem maior, por mais que eu tivesse aplicado o padrao da maneira indicada e nao sei o que mais, ainda assim eu teria que reimplementar todos os daos, um a um. Eu, com certeza precisaria ter a hierarquia SqlServerDAO e PostgreDAO, e nao tem nada de facil nisso.

Acho que esses "root of all evil" que tem surgido. Otimizacao, flexibilizacao, encapsulamento, vem apenas confirmar uma regra primaria do Extreme Programming: KISS (keep it simple, stupid).

Editado só pra conclusao:
O que me dá medo mesmo são as más interpretações dessas coisas.

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 517 Offline

sergiotaborda wrote:Não vou acessar o banco real durante os testes, nem me vou dar ao trabalho de ter um banco de testes. Eu não estou testando o acesso ao banco (eu confio no jdbc) e sim as features do sistema. Então é comum utilizar algum tipo de objecto que encapsula o acesso a dados ( não necessáriamente um DAO ou um DomainStore) e posso mudar sem causar problemas no resto da aplicação.

Fugindo um pouco do assunto principal do topico, mas nao pude deixar de notar.

Com um banco de testes voce nao vai testar o jdbc, vai testar se seu esquema e se seu mapeamento objeto-relacional estao corretos, vai manter os testes la para que eles indiquem que continuam corretos a cada alteracao no modelo de objetos ou no esquema do banco. E voce nao pode fazer isso no seu banco de desenvolvimento, menos ainda no de producao, porque nao vai conseguir manter os dados sempre no mesmo estado para que os testes seja realizadao. Entao é fundamental que haja um banco de testes.

Do contrario seus dados nao existem (baseado na afirmacao de que uma funcionalidade só existe se existe um teste pra ela).

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

YvGa wrote:

sergiotaborda wrote:Não vou acessar o banco real durante os testes, nem me vou dar ao trabalho de ter um banco de testes. Eu não estou testando o acesso ao banco (eu confio no jdbc) e sim as features do sistema. Então é comum utilizar algum tipo de objecto que encapsula o acesso a dados ( não necessáriamente um DAO ou um DomainStore) e posso mudar sem causar problemas no resto da aplicação.

Fugindo um pouco do assunto principal do topico, mas nao pude deixar de notar.

Com um banco de testes voce nao vai testar o jdbc, vai testar se seu esquema e se seu mapeamento objeto-relacional estao corretos, vai manter os testes la para que eles indiquem que continuam corretos a cada alteracao no modelo de objetos ou no esquema do banco.

Mas afinal você está testando a sua aplicação ou o seu uso do framework X ?
Como eu disse , ou vc confia no ORM que usa, ou não confia. Para testar uma funcionalidade de transação de conta vc precisa de banco de dados ?
Para quê ? Para ter a certeza que ficou gravado ? Ora, o ponto não saber se ficou gravo, é saber se os valores são corretos. E para isso não precisa de um banco de dados. Ou melhor, vc precisa de um banco de dados (definição formal) mas não de um SGDB.

Entao é fundamental que haja um banco de testes.

Em sistema orientados a dados até poderia concorda contigo, mas em sistemas direcionados ao tratamento de entidades , não.
Não é fundamental ter um banco de dados SGDB. Um map ou um list resovlem a maior parte dos testes.
Mas como falei antes, se não confia no seu ORM, então, ok, por todos os meios use um banco de dados. Só se lembre de cumprir o mandato de testes que implica em que o estado antes e depois do teste tem que ser o mesmo. i.e. não se esqueça de apagar o que gravou de novo ou gravar o que apagou durante o teste. Agora... vc acha que esse tipo de controle de consistência do banco é algo fundamental ? Eu não acho. Acho chato e sem propósito ( mesmo com DBUnit é melhor não precisa do DBUnit).

Adendo:
O conceito de banco de testes só existe poruqe vc usa o hibernate/jpa que não são domianstores verdadeiros no sentido que não permitem escrever/ler para outos formatos. Se vc tiver um framework com esse poder, vc não vai precisar ter um banco de dados.

Um exemplo muito facil de eliminar o banco durante os testes é usar mocks de repositorios. Como as interfaces do repositorio são simples e orientadas ao dominio implementar o retorno é trivial a maior parte das vezes. Muito mais simples que ficar codificando DAO , DBUnit ou qualquer outra tecnica que teimosamente usa o banco de dados.

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 517 Offline

sergiotaborda wrote:
Mas afinal você está testando a sua aplicação ou o seu uso do framework X ?
Como eu disse , ou vc confia no ORM que usa, ou não confia. Para testar uma funcionalidade de transação de conta vc precisa de banco de dados ?
Para quê ? Para ter a certeza que ficou gravado ? Ora, o ponto não saber se ficou gravo, é saber se os valores são corretos. E para isso não precisa de um banco de dados. Ou melhor, vc precisa de um banco de dados (definição formal) mas não de um SGDB.

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.

Um exemplo muito facil de eliminar o banco durante os testes é usar mocks de repositorios. Como as interfaces do repositorio são simples e orientadas ao dominio implementar o retorno é trivial a maior parte das vezes. Muito mais simples que ficar codificando DAO , DBUnit ou qualquer outra tecnica que teimosamente usa o banco de dados.

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.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

YvGa wrote:
Tudo isso que voce disse tem que ser feito, mas alem disso o esquema e o mapeamento TÊM que ser testados.

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.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

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.

sergiotaborda wrote:
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.

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.

This message was edited 1 time. Last update was at 16/07/2009 15:40:55

Bruno Laturner wrote: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.

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.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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

Rubem Azenha wrote: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();

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

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://www.avoka.com/click-examples/cayenne/cayenne-form-page.htm
http://databinder.net/site/show/overview

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 517 Offline

Rubem Azenha wrote: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();

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.

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