Antipatern Dao trabalho de faculdade

Não creio que este enunciado vá contra qualquer destes padrões.

O DAO serve justamente para interfacear o acesso a dados, para que sua lógica não fique pendurada ao seu mecanismo de persistência.
O que o DAO faz para persistir vai depender da implementação (e não da sua interface), portanto utilizar procedures é uma implementação totalmente válida (muito vezes utilizada para aumentar performance ou segurança).

Aliás, utilizar “sql padrão” não garante portabilidade entre bancos. É comum você necessitar de uma feature diferente do padrão ANSI e cada banco a implementa de uma forma diferente. Pegar a data e hora do banco de dados é um exemplo disso.

O padrão MVC não nem nenhuma relação com sua camdada de dados/integração. Ele é um padrão pra divisão de responsabilidades na sua camada de apresentação. O “resto” do sistema não tem influência nele.

Pessoas falam como se mudar de servidor de banco de dados em um projeto é coisa rotineira …

Não é a primeira vez que eu vou me posicionar PARCIALMENTE contra o padrão DAO. (Eu realmente espero que as pessoas leiam esse PARCIALMENTE antes de começarem a me linchar)

DAO é um importante padrão de projeto que te garante a separação do código de integração com o DBMS e o centraliza, levando à um código mais legivel e fácil de manter.

Contudo eu acho que DAO da maneira como a maioria das pessoas o usa é um pouco indequado. É perfeitamente possível se escrever um unico DAO generico e armazenar as suas queries, por exemplo, em arquivos, sem a necessidade de criar depois um novo DAO para cada entidade. Aplicar padrões de nomeação como PessoaDAO, CarroDAO, WTFDAO, indicam a ocorrência de bad smells no seu código, como pode ser visto em vários livros sobre refactoring. Esse bad smell é fácilmente identificavel pelo padrão de nomeação presente nas classes DAO e seus “efeitos colaterais” podem ser sentidos quando você precisa alterar o código de uma entidade e o código do DAO muda por consequência (toda modificação deveria ser localizada) (uma unica alteração não deveria provocar mudanças em mais de um ponto do seu código).

O DAO totalmente genérico é possível como é demonstrado no livro “Real World JEE Patterns” de Adam Bien, ou mesmo pela própria API do JPA que o oferece na classe EntityManager.

Há, também, a idéia de que o DAO oferece uma melhor separação (independencia) do DBMS e que assim ficaria mais fácil de muda-lo no futuro. Agora vamos convir, em quantos projetos vocês já trabalharam passaram por essa situação? Se você já viveu um caso de alterar o DBMS de uma aplicação pronta, em quantos, do total de projetos que você já desenvolveu, isso aconteceu? Na prática, DBMS tendem a durar mais que as próprias aplicações. Isso pode ser visto aqui mesmo no GUJ com o volume de posts de desenvolvedores com problemas para desenvolver novas aplicações para bancos de legado. (Eu, particularmente, não me lembro de nenhum post de alguém com problemas para substituir o banco de uma aplicação de legado, mas também não pocurei). Esse tipo de “precaução” contra possíveis mudaças é, também, um bad smell reconhecido como “Premature Generalization”. Prover mais flexibilidade do que o seu problema realmente precisa apenas porque talvez em um futuro distante alguém quem sabe possa precisar, apenas torna o seu código maior, menos claro e mais difícil de manter.

De qualquer forma não acho que esse seja o caso do seu trabalho de faculdade. Não se trata de uma conformidade com esse ou aquela padrão de projeto. É apenas um meio de você aprender um pouco sobre stored procedures.

Dependendo do produto e do cliente, tem isso sim.

dev.rafael:

Não é a primeira vez que eu vou me posicionar PARCIALMENTE contra o padrão DAO. (Eu realmente espero que as pessoas leiam esse PARCIALMENTE antes de começarem a me linchar)

DAO é um importante padrão de projeto que te garante a separação do código de integração com o DBMS e o centraliza, levando à um código mais legivel e fácil de manter.

Contudo eu acho que DAO da maneira como a maioria das pessoas o usa é um pouco indequado. É perfeitamente possível se escrever um unico DAO generico e armazenar as suas queries, por exemplo, em arquivos, sem a necessidade de criar depois um novo DAO para cada entidade. Aplicar padrões de nomeação como PessoaDAO, CarroDAO, WTFDAO, indicam a ocorrência de bad smells no seu código, como pode ser visto em vários livros sobre refactoring. Esse bad smell é fácilmente identificavel pelo padrão de nomeação presente nas classes DAO e seus “efeitos colaterais” podem ser sentidos quando você precisa alterar o código de uma entidade e o código do DAO muda por consequência (toda modificação deveria ser localizada) (uma unica alteração não deveria provocar mudanças em mais de um ponto do seu código).

O DAO totalmente genérico é possível como é demonstrado no livro “Real World JEE Patterns” de Adam Bien, ou mesmo pela própria API do JPA que o oferece na classe EntityManager.

Há, também, a idéia de que o DAO oferece uma melhor separação (indepedencia) do DBMS e que assim ficaria mais fácil de muda-lo no futuro. Agora
vamos convir, em quantos projetos vocês já trabalharam passaram por essa situação? Se você já viveu um caso de alterar o DBMS de uma aplicação pronta, em quantos, do total de projetos que você já desenvolveu, isso aconteceu? Na prática, DBMS tendem a durar mais que as próprias aplicações. Isso pode ser visto aqui mesmo no GUJ com o volume de posts de desenvolvedores com problemas para desenvolver novas aplicações para bancos de legado. (Eu, particularmente, não me lembro de nenhum post de alguém com problemas para substituir o banco de uma aplicação de legado, mas também não pocurei). Esse tipo de “precaução” contra possíveis mudaças é, também, um bad smell reconhecido como “Premature Generalization”. Prover mais flexibilidade do que o seu problema realmente precisa apenas porque talvez em um futuro distante alguém quem sabe possa precisar, apenas torna o seu código maior, menos claro e mais difícil de manter.

De qualquer forma não acho que esse seja o caso do seu trabalho de faculdade. Não se trata de uma conformidade com esse ou aquela padrão de projeto. É apenas um meio de você aprender um pouco sobre stored procedures.

Concordo com a primeira parte do seu post onde vc menciona o DAO genérico. Se puder eliminar os DAOs específicos, é seu dever de programador faze-lo.
Mas a segunda parte escorregou um pouco. Se você não tiver uma maneira simples de isolar o banco de dados de seu sistema, sua estratégia de testes vai ser muito prejudicada. Não importa se você vai um dia trocar o banco ou suportar mais de um banco (outro caso que vc não levou em conta), você precisa de uma maneira simples de trocar o mecanismo de persistência por outro que seja determinístico e não envolva I/O.

é o seguinte, no meu relatorio do trabalho, eu mencionei que apenas temos vantagens em usar procedures nos casos de termos processamento longo e demorado, porque assim fica mais rapido por ser tudo feito internamente no banco de dados.

Mas imagina a logica do negocio nao deve estar toda no banco de dados, acho isso errado,…
e por outra, se podemos fazer um insert com apenas uma linha " insert into pessoa ( nome, telefone, email etc ) values (? , ? , ? )" para que fazer primeiro codigos em pl/sql, e apenas depois fazermos o insert???

nao vejo vantagem e beneficio neste modelo de programar, execpto no caso que mencionei acima, alguem ve o beneficio???

De fato, quanto estamos desenvolvendo testes de integração, precisamos de meios de substituir o banco de dados de produção por um outro de testes. Eu só não vejo como o uso de um DAO genérico poderia ser um impecilho para isso. Você, certamente, deve separar os parametros de conexão com o banco de modo que essa mudança seja suportada na fase de testes.

Eu não sei se ficou claro, já que frequêntemente quando falo sobre esse tópico as pessoas me confundem, não estou afirmando que não se deva usar DAOs nos seus projetos ou que se deva espalhar o código de acesso ao banco no meio da sua lógica, apenas estou dizendo que existem meios mais simples e elegantes de se fazer isso do que aquele monte de AlgumaCoisaDAO. O JPA implementa o padrão na classe EntityManager e você pode usufruir de todas as vantagens de um DAO sem ter que escrever um.

AbelBueno:

Não creio que este enunciado vá contra qualquer destes padrões.

O DAO serve justamente para interfacear o acesso a dados, para que sua lógica não fique pendurada ao seu mecanismo de persistência.
O que o DAO faz para persistir vai depender da implementação (e não da sua interface), portanto utilizar procedures é uma implementação totalmente válida (muito vezes utilizada para aumentar performance ou segurança).

Aliás, utilizar “sql padrão” não garante portabilidade entre bancos. É comum você necessitar de uma feature diferente do padrão ANSI e cada banco a implementa de uma forma diferente. Pegar a data e hora do banco de dados é um exemplo disso.

O padrão MVC não nem nenhuma relação com sua camdada de dados/integração. Ele é um padrão pra divisão de responsabilidades na sua camada de apresentação. O “resto” do sistema não tem influência nele.

dev.rafael:

Não é a primeira vez que eu vou me posicionar PARCIALMENTE contra o padrão DAO. (Eu realmente espero que as pessoas leiam esse PARCIALMENTE antes de começarem a me linchar)

DAO é um importante padrão de projeto que te garante a separação do código de integração com o DBMS e o centraliza, levando à um código mais legivel e fácil de manter.

Contudo eu acho que DAO da maneira como a maioria das pessoas o usa é um pouco indequado. É perfeitamente possível se escrever um unico DAO generico e armazenar as suas queries, por exemplo, em arquivos, sem a necessidade de criar depois um novo DAO para cada entidade. Aplicar padrões de nomeação como PessoaDAO, CarroDAO, WTFDAO, indicam a ocorrência de bad smells no seu código, como pode ser visto em vários livros sobre refactoring. Esse bad smell é fácilmente identificavel pelo padrão de nomeação presente nas classes DAO e seus “efeitos colaterais” podem ser sentidos quando você precisa alterar o código de uma entidade e o código do DAO muda por consequência (toda modificação deveria ser localizada) (uma unica alteração não deveria provocar mudanças em mais de um ponto do seu código).

O DAO totalmente genérico é possível como é demonstrado no livro “Real World JEE Patterns” de Adam Bien, ou mesmo pela própria API do JPA que o oferece na classe EntityManager.

Há, também, a idéia de que o DAO oferece uma melhor separação (independencia) do DBMS e que assim ficaria mais fácil de muda-lo no futuro. Agora vamos convir, em quantos projetos vocês já trabalharam passaram por essa situação? Se você já viveu um caso de alterar o DBMS de uma aplicação pronta, em quantos, do total de projetos que você já desenvolveu, isso aconteceu? Na prática, DBMS tendem a durar mais que as próprias aplicações. Isso pode ser visto aqui mesmo no GUJ com o volume de posts de desenvolvedores com problemas para desenvolver novas aplicações para bancos de legado. (Eu, particularmente, não me lembro de nenhum post de alguém com problemas para substituir o banco de uma aplicação de legado, mas também não pocurei). Esse tipo de “precaução” contra possíveis mudaças é, também, um bad smell reconhecido como “Premature Generalization”. Prover mais flexibilidade do que o seu problema realmente precisa apenas porque talvez em um futuro distante alguém quem sabe possa precisar, apenas torna o seu código maior, menos claro e mais difícil de manter.

De qualquer forma não acho que esse seja o caso do seu trabalho de faculdade. Não se trata de uma conformidade com esse ou aquela padrão de projeto. É apenas um meio de você aprender um pouco sobre stored procedures.

ok, valeu a opinião, agora entendi o real objectivo, que é exercitar o stored procedure, e gostei da idea do dao generico, em vez de ficar a recodificar muitos codigos nos dao. boas valeu mesmo