DAO's nas classes de negócio

Eu adoro quando as pessoas falam "depois desta teoria toda". É impressionante como alguém consegue ver toda esta diferença entre teoria e prática em OO, por isso que temos tanto software mal-construído.

saoj wrote:
Se eu entendi direito:

req HTTP -> Action -> Modelo -> UserRepository -> Implementação concreta do repositário MySQLUserRepository -> Banco de dados.

Dado que Model = Camada de Aplicação+Camada de Negócios+Camada de Persistência o Repository está dentro da Camada de Negócios enquanto o DAO está dentro da Camada de Persistência.

Acho que você entendeu errado o Model no MVC, por isso esta confusão. Model em MVC é: -> UserRepository -> Implementação concreta do repositório MySQLUserRepository -> Banco de dados. Tudo isso.

saoj wrote:
Parece correto do ponto de vista teórico, mas com o side-effect prático de termos muitas classes e interfaces.

Releia sobre MVC, faça seu DAO implementar um Repositorio e pronto, na prática você vai ter o mesmo número de .java.

saoj wrote:
Acho que esse conceito está difícil de assimilar porque em muitos casos o repositório vai apenas espelhar fielmente o DAO, logo ele parece uma camada a mais apenas com sentido teórico mas nao prático.

Novamente: ele não é uma Camada a mais, ele integra duas Camadas. A dificuldade em ver a aplicação pdoe estar ligada com a falta de uma divisão reald e Camadas, já que MVC em si não tem nada a ver com Camadas.

saoj wrote:
Por exemplo, se eu precisar pegar todos os usuários maiores de X anos, com a cueca da cor Y e cadastrados antes de 1990, terei que criar um novo método no repositorio e um outro igualzinho no DAO.

Não.

Primeiro como já falamos aqui milhões de vezes você não precisa ter uma implementação de Repository que nãos eja um DAO se você não precisar ela (por favor, leia o email que colei antes de responder a este post).

Segundo, você não precisaria ter um método para este tipo de coisa, aliás se você tiver muitos métodos assim é sinal que seu design é bem ruim. Você resolve isso com outra dupla: Specification/QueryObject.

É óbvio que tudo, incluindo padrões DDD, só valem a pena quando valem a pena. É não-tão-óbvio que vale a pena na maioria das vezes, as pessoas usam argumentos fúteis apra não usar e acabam criando sistemas...interessantes do pontod e vista homem/hora apra manutenção.

O Repository não rpecisa sequer ser uma interface. leiam o livro do Eric Evans para entender do que se trata (ou o artigo na MundoJava #17).

RafaelRio wrote:
A questão que eu coloquei é "essa camada a mais vale a pena"? Se o preço para mais uma camada superar os ganhos de tornar "a coisa mais OO", a resposta é não. Taí uma discussão que vai (ou melhor, poderia ir) longe...

mais uma vez: não é uma nova Camada, é a integração entre duas Camdas que já existem feita de uma maneira disciplinada. Simples assim.

RafaelRio wrote:
Ultimamente tenho pensado que vale a pena questionar novas teorias que andam ululando por aí, em pró da simplicidade, desde que com fundamentos, ao invés de simplesmente aceitá-las.

Esse repository, por exemplo, vocês podem argumentar que torna as coisas mais claras, elegantes, o genro que toda sogra gostaria de ter, mais OO, etc. Mas tô sentindo que a reação da maioria das pessoas será "isso é lindo na teoria, mas não na prática; deixa quieto, vou continuar com meus DAO's". Vão deixar (aproveitando esse exemplo) o Repository para uma "zelite" que irá se formar - "isso é só pros caras".

E quando argumentos do tipo "torna a coisa mais OO", "segundo Fowler", etc, finalmente se desgastarem, essa elite ficará isolada numa torre de marfim - já aconteceu e acontece em diversas áreas. Vão dizer coisas lá de cima na torre, as pessoas vão escutar, ficar encantadas, vai entrar por um ouvido e sair pelo outro.

Eu sicneramnete acho que se alguém está lendo uma thread desta ele quer melhorar seus conhecimentos. Pode ser que consiga, pdoe ser que não, mas tomar a atitude sugeria não vai melhorar o nível do emrcado como um todo. Eu já escrevi algumas vezes que acredito num grande cisma tecnológico que irá acotnecer em breve. Através de tecnologias como DSLs os pseudo-profissionais que acham que Repository é "pros caras" vão sair do mercado de tecnologia para se especializar na confecção de aplicações de forma muito simplificada, através de ferramentas de MDD provavelmente.

Enqauntoe ste dia não chega todo mundo aqui é negenheiro e não saber que é Martin Fowler é como um físico que não sabe quem foi Einsten ou Newton (guardadas as devidas proporções de genialidade, claro) e não sabe usar ot rabalho destes mestres no seu dia-a-dia. Ou um engenheiro civil que não sabe edificar um prédio sem usar uns 2 ou 3 modelos pré-concebidos, ele não entende por que faz aquilo e não conseguem mduar nem adaptar os modelos.

Há três anos atrás IoC era coisa "dos caras". Hoje qualquer framework mais ou menos e boa parte de Java EE 5 usa IoC.

RafaelRio wrote:
Não me entendam mal, não estou soando as trombetas do apocalipse e sou fã da fundamentação e da boa literatura. Mas tudo tem limites, cada caso é um caso, teoria ainda é uma teoria, devem ser testadas na prática, por aí vai. (Uauu!! Isso é que bom uso de clichês...)

Testadas? Ok, vamos lá, o que você quer como teste exatamente? São conceitos existentes há uma década que já foram implementados e detalhados zilhões de vezes, o que falta neste sentido?

RafaelRio wrote:
Aceitam uma sugestão? Em casos assim, penso que o ideal seria escrever artigos técnicos com o contexto e os pormenores, como a série sobre exceções do Luca e o artigo sobre DTO do shoes. Um já é referência no tema, o outro, aposto, vai virar.

A partir daí, as pessoas pensam e decidem com suas cabeças qual o melhor caminho.
Abraços!

Não entendi, e o que fizemos nesta thread se não apontar para recursos em artigos e livros e discutí-los?

Acho que estamos começando a ficar repetitivos demais nesse tópico Phillip!

Rafael, muito legal o que você escreveu. Tem o seu valor, mas não concordo com a maioria dos argumentos, achei muito conformista: "não se mexe em time que está ganhando".

Será que está ganhando mesmo?

Acho que o que o Fábio falou sobre OO matou a pau.

Daí se o seu modelo utilizar internamente repositório ou dao ou ambos é problema dele, devendo ser avaliado caso a caso...

pcalcado wrote:Enqauntoe ste dia não chega todo mundo aqui é negenheiro e não saber que é Martin Fowler é como um físico que não sabe quem foi Einsten ou Newton

Não sei se você sabe, mas as teorias de Newton e Einsten são questionadas a toda hora. Aliás, o próprio Einstein quebrou as perninhas do Newton quando a teoria da relatividade foi aceita. O interessante é que mesmo assim as duas podem ser utilizadas, uma melhor que a outra de acordo com o contexto.

Só quis dizer que não é porque uma teoria vem de um lugar que ela simplesmente deve ser aceita, senão estamos aceitando argumentos de autoridade - uma falácia. O que sugeri foi mais demonstrações, além de citações.

pcalcado wrote:Há três anos atrás IoC era coisa "dos caras". Hoje qualquer framework mais ou menos e boa parte de Java EE 5 usa IoC.

Você não entendeu o que eu quis dizer. Se ler com atenção, vai perceber que gostaria que argumentos desse tipo não fossem utilizados, não estou colaborando com eles. Ou seja, não é pra ficar só "com os caras". Nem é pra existir "os caras" isolados numa Torre de Marfim.

[editado]Você que gosta de conceitos, procure descobrir o que quer dizer Torre de Marfim. Isso vai te ajudar a entender o que escrevi e a minha preocupação.[/editado]

pcalcado wrote:Não entendi, e o que fizemos nesta thread se não apontar para recursos em artigos e livros e discutí-los?

Eu mesmo apontei pra alguns. Que tal mais deles? Você também não prestou atenção num deles, que diz que Repository deve ter uma implementação própria e não apenas ser implementado por um DAO.

pcalcado wrote:Testadas? Ok, vamos lá, o que você quer como teste exatamente? São conceitos existentes há uma década que já foram implementados e detalhados zilhões de vezes, o que falta neste sentido?

Se você ficar bravinho, eu não brinco mais!

Quero mais acessos a esses testes, eu mesmo quero testar.

[editado]Aqui você me redimiu. Enquanto abusei dos clichês, você fez bom uso de hipérboles"

[/editado]

Fabio Kung wrote:Rafael, muito legal o que você escreveu. Tem o seu valor, mas não concordo com a maioria dos argumentos, achei muito conformista: "não se mexe em time que está ganhando".

Será que está ganhando mesmo?

Fábio, a que vc está se referindo? Quem disse "não se mexe em time que está ganhando"?

Na verdade, eu não tomei uma posição contra Repository; nem a favor. Vou parar por aqui, porque vai ficar cíclico mesmo. Pra entender melhor como penso, é só voltar um pouquinho e reler o que escrevi.

Olá

Esta discussão está muito boa mas vou dar meu pitaco meio em cima do muro.

Primeiro uma coisa óbvia: Arquitetura do sistema vale mais em termos de negócio do que sob o ponto de vista estritamente OO. Não adianta apenas caprichar no OO.

Quem usa DTO, aprendeu assim e faz bons sistemas usando DTO, que continue assim. Não acredito que vá perder os prazos por escrever umas classezinhas a mais

Quem ainda está aprendendo, procure por alternativas que só usam DTO em casos muitos especiais que é justamente como o Phillip recomenda. Na maioria dos sistemas DTO não é necessário.

É como EBJs antes do 3.0 que também só eram úteis em pouquíssimos casos (*).

Quanto ao DAO ser interface ou não, há muitos autores que fazem assim. Quem quiser fazer, que o faça. Só procure ser coerente com sua equipe.

A verdade é que eu ainda não consegui uma receita de bolo que sirva para todos os sistemas. Neste ponto estou com o Rafael: se alguém tem a receita então vamos publicar.

(*) Na minha opinião, EJBs anteriores ao 3.0 foram a maior besteira já inventada na área de TI. Me desculpe o amigo Kenobi, mas tenho até pena das empresas que ficarão com este legado (bem usado ou não como na maioria dos casos).

[]s
Luca

pcalcado wrote:[
Ou eu não tô sabendo explicar ou tem algo errado na comunicação...

Imagine a situação: o seu DAO recebe como parâmetro um HttpRequest. Tem o mesmo efeito que passar um objeto de negócios para ele, não?

????????????????????????????????

Não consigo imaginar essa situação. Enfim, volto a dizer que, no final, o efeito de usar uma interface chamada DAO ou repository é o mesmo.

Luca wrote:Olá

Esta discussão está muito boa mas vou dar meu pitaco meio em cima do muro.

Primeiro uma coisa óbvia: Arquitetura do sistema vale mais em termos de negócio do que sob o ponto de vista estritamente OO. Não adianta apenas caprichar no OO.

Quem usa DTO, aprendeu assim e faz bons sistemas usando DTO, que continue assim. Não acredito que vá perder os prazos por escrever umas classezinhas a mais

Quem ainda está aprendendo, procure por alternativas que só usam DTO em casos muitos especiais que é justamente como o Phillip recomenda. Na maioria dos sistemas DTO não é necessário.

É como EBJs antes do 3.0 que também só eram úteis em pouquíssimos casos (*).

Quanto ao DAO ser interface ou não, há muitos autores que fazem assim. Quem quiser fazer, que o faça. Só procure ser coerente com sua equipe.

A verdade é que eu ainda não consegui uma receita de bolo que sirva para todos os sistemas. Neste ponto estou com o Rafael: se alguém tem a receita então vamos publicar.

(*) Na minha opinião, EJBs anteriores ao 3.0 foram a maior besteira já inventada na área de TI. Me desculpe o amigo Kenobi, mas tenho até pena das empresas que ficarão com este legado (bem usado ou não como na maioria dos casos).

[]s
Luca

Luca, só falando um pouquinho de EJB e suas necessidades, você lembra como era implementar tais requisitos com Corba ?

Já vi projetos para ramos de telefonia levarem anos para serem implementados em Corba e fracassarem a mesma equipe tentando com a infra EJB e em 4 meses entregando ao cliente funcionando.

A verdade é que se você tem necessidades densas, implementar Servant em C ou C++ é muito mais complicado do que se imagina e nem sempre temos tais profissionais disponíveis no mercado.

A especificação anterior à 3.0 possui falhas sim, como ORM - EntityBeans, mas possui muitas coisas legais também como MDBs, SessionBeans, controlole de transações, IIOP - implementar isso na mão é um parto.

Acho que muitos crucificam EJBs pois a espcecificação é bem abrangente e árdua para alguns profissionais,mas ainda sim, mais simples do que fazer tudo na mão.

Lembrando que antigamente não existiam frameworks para controlar transações como o Spring, que veio anos mais tarde, nem soluções como TerraCotta , que na minha opinião ainda precisa ser justificada pelo ROI.

Hoje implementar um sistema tolerante à falhas com a especificação é relativamente simples e com grandes opções sem custos de aquisição de software - GlassFish por exemplo, desde a versão 7.1 do App da Sun, foi incorporado uma tecnologia de cluster da Clustra, empresa que fazia grandes sistemas de cluster para empresas de Telecom.

paper para quem se interessar : http://www.vldb.org/conf/1995/P469.PDF

Acho que além da especificação, vale à pena os profissionais conhecerem também os produtos que a implementam, pois há muitas particularidades, como controle de Sessão, que até um tempo atrás o Websphere fazia por intermédio do DB2 ou pelo servidor, mas com 2GB de informações o mesmo caia e com o SunApp, você podia usar a estratégia de cluster do HADB - High Available Data Base e não onerar a performance com acessos a um DB externo por exemplo.

Finalizando, eu não tenho dó de empresas que usam a especificação EJB e a possuem de legado e sim daquelas que a utilizaram de maneira errônea, possuem um legado mal projetado por profissionais não capazes , conhecedores superficiais da especificação, ambientes e produtos.

Olá

Kenobi, eu não disse que não era necessário desenvolver uma solução para os problemas que o EJB < 3.0 tentou resolver. E lembre-se que o RMI usado pelos EJBs é mais simples do que CORBA porque é papo de Java com Java.

Eu disse e repito que a solução proposta pelo EJB < 3.0 é horrível e foi uma péssima idéia. Acredito que a própria Sun pense assim hoje porque mudou quase tudo nos EJBs a partir da versão 3.0.

O problema existia, o ruim foi ter sido resolvido por gente incompetente. Já vi este filme em muitas empresas, ou seja, ter que refazer tudo porque o sistema era uma droga.

Por este motivo tenho pena dos infelizes que darão suporte ao enorme legado de EJBs < 3.0. E ainda com 2 agravantes:
1) EJBs do tempo em que tudo era remoto
2) EJBs que foram usados indevidamente, às vezes, só para o desenvolvedor aprender a tecnologia.

Sem falar nos infelizes que usam caros servidores de aplicação obsoletos massageados por consultoras e que agora estão com sistemas engessados. Tem pelo menos um grande banco nesta situação.

[]s
Luca

Olá

Galera, desculpa a fuga do assunto do tópico.

Kenobi wrote:
Hoje implementar um sistema tolerante à falhas com a especificação é relativamente simples e com grandes opções sem custos de aquisição de software - GlassFish por exemplo, desde a versão 7.1 do App da Sun, foi incorporado uma tecnologia de cluster da Clustra, empresa que fazia grandes sistemas de cluster para empresas de Telecom.

paper para quem se interessar : http://www.vldb.org/conf/1995/P469.PDF

Acho que além da especificação, vale à pena os profissionais conhecerem também os produtos que a implementam, pois há muitas particularidades, como controle de Sessão, que até um tempo atrás o Websphere fazia por intermédio do DB2 ou pelo servidor, mas com 2GB de informações o mesmo caia e com o SunApp, você podia usar a estratégia de cluster do HADB - High Available Data Base e não onerar a performance com acessos a um DB externo por exemplo.

Cuidado, não bem assim. O HADB é o novo nome do Clustra. Segundo o pessoal técnico do glassfish, se você não precisa de alta disponibilidade com 5 noves, o HADB é overkill. Veja:

http://blogs.sun.com/theaquarium/entry/in-memory_replication_in_glassfish_v2

eduardo pelegri-llopart wrote:
Clustra is a very sophisticated tool. It is a good solution if you need the 5 9's availability it delivers, but it is an overkill otherwise. We truly believe that most customers will be much better off with the in-memory replication.

[]s
Luca

microfilo wrote:Enfim, volto a dizer que, no final, o efeito de usar uma interface chamada DAO ou repository é o mesmo.

Rubem, em boa parte dos casos vai ser realmente só uma questão de nomenclatura. Mas como o Phillip já disse, nomenclatura é bastante importante.

Se as classes de domínio tem referência, é uma boa chamar de Repository. Caso contrário pode chamar de Dao. Mas claro, isso não é verdade absoluta (não existe verdade absoluta).

Luca wrote:Olá

Galera, desculpa a fuga do assunto do tópico.

Kenobi wrote:
Hoje implementar um sistema tolerante à falhas com a especificação é relativamente simples e com grandes opções sem custos de aquisição de software - GlassFish por exemplo, desde a versão 7.1 do App da Sun, foi incorporado uma tecnologia de cluster da Clustra, empresa que fazia grandes sistemas de cluster para empresas de Telecom.

paper para quem se interessar : http://www.vldb.org/conf/1995/P469.PDF

Acho que além da especificação, vale à pena os profissionais conhecerem também os produtos que a implementam, pois há muitas particularidades, como controle de Sessão, que até um tempo atrás o Websphere fazia por intermédio do DB2 ou pelo servidor, mas com 2GB de informações o mesmo caia e com o SunApp, você podia usar a estratégia de cluster do HADB - High Available Data Base e não onerar a performance com acessos a um DB externo por exemplo.

Cuidado, não bem assim. O HADB é o novo nome do Clustra. Segundo o pessoal técnico do glassfish, se você não precisa de alta disponibilidade com 5 noves, o HADB é overkill. Veja:

http://blogs.sun.com/theaquarium/entry/in-memory_replication_in_glassfish_v2

eduardo pelegri-llopart wrote:
Clustra is a very sophisticated tool. It is a good solution if you need the 5 9's availability it delivers, but it is an overkill otherwise. We truly believe that most customers will be much better off with the in-memory replication.

[]s
Luca

Luca , vi que deu uma pesquisada sobre o assunto e encontrou uma opinião sobre. Entretanto, eu tenho a experiência prática e sei que em sistemas distribuídos onde há de fato a exigência de tolerância à falhas, essa é uma solução extremamente poderosa, que muitos profissionais ainda não conhecem.

Se alguém tentou fazer replicação de sessão e passou problemas de latência ou performance, sabe do que estou falando.

Para findar, acho que a especificação tem falhas sim, mas tem pontos legais, como afirmei outrora.

Construir serviços de alta disponibilidade, como SessionBeans, MDBs - serviços de mensageria, acesso remoto (corba); exigiria um desvio muito grande do projeto, para focar em questões de INFRA, que o framework te provê.

Há também produtos, que podem fazer toda a diferença, como BEA um dos melhores (senão o melhor) produto com muitas características que podem de fato trazer um incremento à solução.

A especificação 3.0 trouxe uma série de benefícios, como simples configuração, debugger entre outros. Mas com as IDEs de hoje em dia, Debugar ficou mais simples, pode atachar via RMI. Você não tem mais a necessidade de implementar uma porrada de interfaces, nem colocar se é local ou remota, agora está automatico a paradinha ...entretanto, um bom desenvolvedor, implementaria um Façade para acesso remoto e para os outros Sessions internos aos módulos, usaria interface local. O lookup dá infinitamente menos trabalho fazendo uso de IoC, mas na especificação anterior você poderia utilizar Patterns para contornar a situação, como ServiceLocator, não é o melhor dos mundos, mas confere um certo grau de organização e produtividade.

Dá mais trabalho, mas o resultado não está tão diferente.

O que mudou mesmo foi a JPA , EntityManager, a forma de configurar tudo aí realmente é outro assunto.

O que não entendo é porque sempre colocam EJB == EntityBeans ? - Entity é só uma parte da especificação, podre por sinal

.

Então, em miúdos, minha estrutura ficaria assim:

view > controller > model > repository > dao > sgbd

Sendo que:
Se eu não utilizar minhas classes de dominio como somente VO ou DTO, farei o uso da dependência do repository o qual terá acesso indireto a camada Dao.

Se eu usar DTO's ou VO's, chamarei da minha classe que trata negócio, os métodos da interface repository ou Dao.

É isso ?!?

[]'s

microfilo wrote:

pcalcado wrote:Não consigo imaginar essa situação. Enfim, volto a dizer que, no final, o efeito de usar uma interface chamada DAO ou repository é o mesmo.

Pense em Camadas. Repository faz com queobjetos de negócios só pensem em objetos de negócio. Leia Robert C. Martin sobre inversão de dependências.

marciobarroso wrote:Então, em miúdos, minha estrutura ficaria assim:

view > controller > model > repository > dao > sgbd

Não, releia minha mensagem para p saoj.

marciobarroso wrote:
Sendo que:
Se eu não utilizar minhas classes de dominio como somente VO ou DTO, farei o uso da dependência do repository o qual terá acesso indireto a camada Dao.

Se eu usar DTO's ou VO's, chamarei da minha classe que trata negócio, os métodos da interface repository ou Dao.

Por que você suaria VO/DTO em primeiro lugar?

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