Premature Encapsulation is the Root of All Evil

Estava lendo esse artigo:
http://www.adam-bien.com/roller/abien/entry/premature_encapsulation_is_the_root

Ok, o texto é bem exploratório, mas me fez pensar.

Em 12 anos trabalhando profissionalmente na área posso contar nos dedos quantas vezes precisei alterar a base de dados do meu programa. Nessa única vez, mesmo com todos os DAOs, o trabalho se mostrou hercúleo e praticamente inviável. E olha que estava trocando de um banco que suporta o supostamente padrão SQL, por um outro de mesmo tipo.

Por isso, pergunto aos senhores. Algum de vocês já foi realmente beneficiado por usar DAOs? Realmente justifica-se a complexidade adicional inserida no código, os frameworks para gerencia-los, e demais problemas que o aumento da complexidade como um todo geram?

Java Ninja Membro desde: 27/01/2005 11:41:47 Mensagens: 296 Offline

O real benefício dos DAOs pode ser melhor visualizado quando você tem mais de uma fonte de dados (além do tradicional banco de dados relacional). Imagine recuperando informações sobre seu modelo de mais de uma fonte - você vai perceber os benefícios do DAO e do DomainStore.

Ser capaz de abstrair o acesso aos dados utilizando componentes comuns e reutilizáveis é uma grande vantagem. Sem contar que, aliado a um modelo de entidades bastante coeso e bem modelado, você facilita muito o desenvolvimento das camadas superiores. Eu tenho sempre DAOs "genéricos" disponíveis no código, e eles facilitam muito o desenvolvimento. O que eu NÃO faço é construir DAOs para diferentes entidades sem haver uma necessidade justificável para isso.

Acho que o grande problema com DAOs é que hoje eles estão supervalorizados; serviços com acessos à contextos de persistência costumam substituir código de DAOs com facilidade e presteza.

Eu uso DAO para não ter código de Hibernate/JPA/ETC espalhado pela aplicação inteira.

prefiro ter um DAO e fazer

do que

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

Eu concordo com o texto, e acho que isso cai naquela discussao do outro topico sobre daos e repositorios, pq eu preciso a abstracao das camadas dao e etc... se eu tenho uma api simples como jpa ou hibernate pra trabalhar?

No principio eu discordava, achava que precisava de um repositorio e ele delegava para os daos, ai eu tinha as interfaces dao, as implementacoes do hibernate e por ai vai, mas a unica coisa em que isso resultava era trabalho extra. Passei a escrever os metodos de busca diretamente na implementacao do repositorio e pronto. Bem mais simples e nao perco em nada a organizacao.

Agora vale deixar claro pra quem for ler o texto, pra nao confundir o nao encapsulamento prematuro com bagunca. Nao eh porque vc nao precisa de toda uma hierarquia de interfaces e implementacao do pattern dao que voce vai ficar enfiando chamada a api do hibernate/jpa/etc no meio das regras de negocio.

Usei os daos como exemplo, mas isso serve pra qualquer camada adicional que seja feita so por modismo, ou porque alguem "leu em algum lugar".

Sobre mudar o banco de dados eu ja precisei fazer mais de uma vez, do firebird para o sql server porque o cliente tinha a licenca e nao queria abrir mao e depois passei a usar o postgre como banco padrao. O tempo que levou foi o de criar o esquema no outro banco e alterar a configuracao do hibernate. Claro que isso foi gracas ao hibernate e nao aos daos, mas eh uma coisa que acontece.

Olá. Eu ainda tenho pouca experiência nessa área, mas acredito que a criação de camadas de abstração deva ser algo que se justifique de acordo com a necessidade. Pelo que entendi no artigo o cara meio que critica a utilização do padrão DAO por "costume", sem que se reflita antes sua real necessidade naquele contexto, ainda mais em situações nas quais já temos outras camadas de abstração como a JPA.
Mas mesmo assim eu acho interessante quando possível ter um DAOGenerico que encapsule o máximo da JPA ou JDBC, dependendo do projeto.

Tipo:

E nos bastidores então tratar as chamadas da JPA.

[]'s
Fred

Eu acredito na necessidade de daos somente quando existem diversas consultas repetitivas nos códigos, quando se usa um EJB Container, onde cada consulta esta atrelada a um metodo e vc pode injetar os beans em outros beans, não vejo necessidade alguma de usar um DAO. Mas em uma aplicação para evitar diversas consulta repetitivas acredito que DAOs para centralizar as consultas são necessários sim.

[]'s

javaBeats wrote:O real benefício dos DAOs pode ser melhor visualizado quando você tem mais de uma fonte de dados (além do tradicional banco de dados relacional). Imagine recuperando informações sobre seu modelo de mais de uma fonte - você vai perceber os benefícios do DAO e do DomainStore.

Claro, foi para isso que os DAOs foram feitos. Mas o questionamento é justamente esse. Na absurda maioria das vezes, você não tem mais de uma fonte de dados. Ou não vai mudar o seu acesso. Ou, mesmo com os DAOs, o trabalho vai ser extremamente complexo (escrever vários DAOs também é bastante difícil, especialmente se sua aplicação já passou por otimizações para aquela base de dados).

javaBeats wrote:Ser capaz de abstrair o acesso aos dados utilizando componentes comuns e reutilizáveis é uma grande vantagem. Sem contar que, aliado a um modelo de entidades bastante coeso e bem modelado, você facilita muito o desenvolvimento das camadas superiores.

Bastante vantagem? Mas é uma vantagem para algo que potencialmente você não vai usar?

javaBeats wrote:Acho que o grande problema com DAOs é que hoje eles estão supervalorizados; serviços com acessos à contextos de persistência costumam substituir código de DAOs com facilidade e presteza.

É, acho que é mais ou menos por aí também. A gente vê muita gente no GUJ partindo para DAOs, VOs e frameworks complexas sem nem sequer se perguntar o porque.

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

ViniGodoy wrote:

javaBeats wrote:O real benefício dos DAOs pode ser melhor visualizado quando você tem mais de uma fonte de dados (além do tradicional banco de dados relacional). Imagine recuperando informações sobre seu modelo de mais de uma fonte - você vai perceber os benefícios do DAO e do DomainStore.

Claro, foi para isso que os DAOs foram feitos. Mas o questionamento é justamente esse. Na absurda maioria das vezes, você não tem mais de uma fonte de dados. Ou não vai mudar o seu acesso.

Isso é parcialmente verdade. "Maioria das vezes" ... hummm ...

No meus sistema é raro quando eu não preciso ter mais do que uma fonte de dados. A razão é simples : testes automáticos.
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.

O texto que referiste está equivocado. Ok, é verdade que a maioria das pessoas não sabe construir uma arquitetura e abusa de pseudo-padrões ( cosias que o cara acha que implementa o padrão X, mas não realidade não) Mas quando vc tem que testar o sistema de forma automática o uso de padrões não apenas é correto como é mandatório. O mecanismo de teste ( O Junit) cria um ambiente de execução diferente do habital para a aplicação e isso força configurações diferentes e o "encaixe" de peças diferentes na estrutrua. Trocar um serviço real que conecta ao sistema X por outro que responde um objeto fixo e simula a comunicação , ou substituir o serviço real por um que lança execptions é prática comum. Esta necessidade de agradar a dois clientes/ambientes força um design melhor e o melhor design é automáticamente mais flexivel.

Usar OO corretamente nunca fez mal a ninguem. Esta conversa de que usar padrões de mais é errado é de quem não sabe usar padrões. É desculpa de mau pagador (aluno).

Se vc quer testes automáticos , vc os quer rápidos. E isso passar por trocar a fonte de dados.
Por outro lado, ao fazer teste é prático ter um conjunto de dados que simulam as várias situações dos testes. É dificil ter estes dados e são construidos junto com os testes num processo iterativo. O ponto é que vc precisa ter controle sobre eles. Isso normalmente pode ser feito substituindo a fonte de dados.

Não estou dizendo que é facil. É dificil. E por isso a maioria das pessoas não o faz. E por consequencia não usa testes automáticos. Mas se vc usa testes automáticos vc é inevitável usar um design mais flexivel. Às vezes isso o obriga de não usar alguma framework da moda só para poder ter testes automáticos. É um trade-off importante. Tlv o mais importante ao construir uma aplicação OO.

Java Ninja Membro desde: 27/01/2005 11:41:47 Mensagens: 296 Offline

Uma boa conclusão que podemos tirar dessa discussão é a necessidade de refletir bastante antes de começar a codificar, sobre quais as reais necessidades do seu projeto. E não adotar tecnologias e padrões baseados em o quão legal isso vai se encaixar no seu currículo, ou o quão complexo o sistema PODERÁ ficar no futuro (pseudo-requisitos), etc.

O que acontecia com frequência até pouco tempo atrás é o uso exagerado de "buzzwords" no ciclo de desenvolvimento, em caráter experimental, afim de se familiarizar com uma tecnologia/pattern para conhecimento próprio/da empresa, sem avaliar a real necessidade da aplicação da mesma a longo prazo no projeto. Tenho encontrado esse comportamento cada vez menos em equipes de novos projetos, o que me leva a crer que a comunidade está se conscientizando nesse sentido, e arquitetos malucos estão perdendo espaço para projetos funcionais e ágeis

This message was edited 1 time. Last update was at 16/07/2009 09:14:14

sergiotaborda wrote:
Se vc quer testes automáticos , vc os quer rápidos. E isso passar por trocar a fonte de dados.
Por outro lado, ao fazer teste é prático ter um conjunto de dados que simulam as várias situações dos testes. É dificil ter estes dados e são construidos junto com os testes num processo iterativo. O ponto é que vc precisa ter controle sobre eles. Isso normalmente pode ser feito substituindo a fonte de dados.

Concordo parcialmente, é fácil vc ter uma base em mysql e nos testes usar H2 ou HQSQL ou outras similares, onde vc tem total controle e pode testar repetidamente as mesmas situações.

Se não existe nenhum código otimizado especificamente para uma base de dados, apenas mudando o persistence.xml vc resolve esse problema, porém em aplicações mais complexas isso não é suficiente e realmente acaba sendo necessário uma abordagem diferenciada.

De qq forma um código otimizado pode não funcionar na base de testes, por algum tipo de limitação e no final vc pode acabar tendo de ter uma base Mysql tb para testes.

O problema que o DAO visa resolver não é trocar a fonte de dados. Mas interoperar entre fontes de diferentes tipos.

Geralmente, quando faço testes unitários, rodo no mesmo tipo de fonte. Isso é, se vou usar SQL server, tenho uma base de testes no próprio SqlServer. Se vou usar MySql, terei uma base de testes no próprio MySql.

Isso evita surpresas também. Quanto mais próximo os testes forem do ambiente real, melhor.

E, para trocar entre fontes de mesmo tipo, o DAO simplesmente não é necessário.

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

ViniGodoy wrote:O problema que o DAO visa resolver não é trocar a fonte de dados. Mas interoperar entre fontes de diferentes tipos.

Geralmente, quando faço testes unitários, rodo no mesmo tipo de fonte. Isso é, se vou usar SQL server, tenho uma base de testes no próprio SqlServer. Se vou usar MySql, terei uma base de testes no próprio MySql.

Normalmente uso uma implemenação em memoria com Map. Previamente carrega com o dados de teste. A minha fonte de dados não é o banco de dados. Então sim, diferentes "tipos" de fonte de dados. ( é que para mim o tipo está incluso da def de fonte de dados)

Isso evita surpresas também. Quanto mais próximo os testes forem do ambiente real, melhor.

Não necessáriamente. Se vc inclui o banco em todos os testes vc inclui um overhead desnecessário. A menos que vc não confie no seu ORM não ha necessidade dessas chamadas todas. Se vc não confia realmente no ORM vc faz testes apenas relativos ao ORM e não do resto do sistema.
Além disso vc deve ter testes de integração e ai sim todo o processo é exercitado. Mas para criar classes e ver se elas funcionam comunicar com o banco pode ser overkill.

E, para trocar entre fontes de mesmo tipo, o DAO simplesmente não é necessário.

Não tão rápido ... Fazer um select para paginação em SQLServer é bem diferente do que para Postgress. O DAO é suposto encapsular esta diferença. Então mesmo para fontes do mesmo tipo ("banco de dados") ainda precisa ter diferentes implementações. ( Claro, com um design bom, vc minimiza essas implementações repetitivas , pelo uso de dialectos, por exemplo, mas mesmo assim ...).
O ponto é que no geral vc sim precisa mudar de DAO (aliás é para isso que ele serve). NO caso particular e dependendo da sua arquitetura e maturidade do seu framework de negocio / applicação pode não ser necessário. Dizer que não é necessário sempre, é ir longe demais.

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

Edufa wrote:
Concordo parcialmente, é fácil vc ter uma base em mysql e nos testes usar H2 ou HQSQL ou outras similares, onde vc tem total controle e pode testar repetidamente as mesmas situações.

Se não existe nenhum código otimizado especificamente para uma base de dados, apenas mudando o persistence.xml vc resolve esse problema, porém em aplicações mais complexas isso não é suficiente e realmente acaba sendo necessário uma abordagem diferenciada.

De qq forma um código otimizado pode não funcionar na base de testes, por algum tipo de limitação e no final vc pode acabar tendo de ter uma base Mysql tb para testes.

Tudo isso é resolvido facilmente se você não programar para banco de dados. Se vc programar para interfaces e via OO esse problema não se coloca.

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

Acho que eu entendi o texto diferente de voce, Sergio. Pelo que entendi o autor se refere ao encapsulamento prematura daquilo que nao precisa ser encapsulado. Sem pensar nos porques do que esta sendo feito.

Por exemplo, (e eu mesmo ja defendi essa pratica aqui) por que eu preciso de toda a abstracao e encapsulamento das camadas de acesso a dados definidas pelo padrao DAO, se os proprios frameworks ORM ja me dão esse encapsulamento, o unico cuidado que eu preciso é nao misturar os codigos dessas apis com as minhas regras. Mas nao creio que seja isso que foi indicado no texto.

Talvez eu tenha lido de forma relapsa, mas a intencao do autor era indicar o porque de encapsular o que ja esta encapsulado, era de criticar o fato de se fazer alguma coisa só porque em algum lugar se leu que é assim, sem questionar, sem testar outras formas, sem buscar outras solucoes. E essa é a coisa que mais vejo por ai. Vou encapsular porque diz que encapsular é certo. E essas coisas nos levam a encontrar, como encontrei, uma aplicacao dividida em duas pra encapsular a regra num web service, que jamais sera usado em outra aplicacao, apenas pra separar apresentacao da logica.

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

Eu já li um texto que toca mais ou menos nesse assunto, mas se chama Premature Flexibilization Is The Root of Whatever Evil Is Left. Basicamente, é a atitude de deixar as coisas muito complexas sobre o pretexto de deixar flexível, só que a própria complexidade se torna fonte de rigidez.

Eu não acho errado o DAO, acho errado outras coisas que o pessoal faz com persistência, do tipo: gerar DAO em cima do Hibernate, ou então criar um DAO genérico...

Ou pior ainda, para cada tabela do banco, criar um CRUD pro usuário. Ora, CRUD é raro num sistema bem feito e se localiza mais ou em conceitos que não são o core ou em configurações. Os outros casos são regras de negócio que contém algum tipo de operação de persistência, mas que fica oculto para o usuário. O problema é que basicamente os programadores preferem seguir um script previsível de menus com "inserir blablablá", "alterar blablablá", "consultar blablablá" e "remover blablablá", esquecendo até mesmo que o usuário não pensa em termos de banco de dados. Um sistema com apresentação ao usuário ruim desse jeito, não vale nem a pena criar DAOs para encapsular regra do banco. O programador expôs o banco ao usuário!

Quando ocorre uma preocupação da necessidade do usuário, e o sistema usa termos familiares, não dos desenvolvedores, mas de quem a utiliza. É natural aparecer a famosa "regra de negócio", onde se percebe que é esquisito misturr essas regras com acessos "crus" de banco. O DAO passa a ser uma solução natural para resolver isso.

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