DAO's nas classes de negócio

Programação Arquitetura
#61

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.

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 é: -&gt UserRepository -&gt Implementação concreta do repositório MySQLUserRepository -&gt Banco de dados. Tudo isso.

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

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.

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).

#62

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

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.

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?

[quote=RafaelRio]
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![/quote]

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

#63

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

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?

#64

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…

#65

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.

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]

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.

Se você ficar bravinho, eu não brinco mais! :twisted: 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" :lol: [/editado]

[quote=Fabio Kung]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?[/quote]
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.

#66

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

#67

[quote=pcalcado][
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?[/quote]

???

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.

#68

[quote=Luca]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[/quote]

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.

#69

Olá

Kenobi, eu não disse que não era necessário desenvolver uma solução para os problemas que o EJB &lt 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 &lt 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 &lt 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

#70

Olá

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

[quote=Kenobi]
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. [/quote]

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

[quote=eduardo pelegri-llopart]
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. [/quote]

[]s
Luca

#71

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).

#72

[quote=Luca]Olá

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

[quote=Kenobi]
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. [/quote]

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

[quote=eduardo pelegri-llopart]
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. [/quote]

[]s
Luca[/quote]

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 :slight_smile: .

#73

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

#74

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.

#75

[quote=marciobarroso]Então, em miúdos, minha estrutura ficaria assim:

view > controller > model > repository > dao > sgbd
[/quote]

Não, releia minha mensagem para p saoj.

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

#76

Tipica discussao interessante que só tem fim quando alguem desiste de escrever…

Eu concordo com argumentos de vários que escreveram

1 - nomes são importantes pois criam um vocabulário em comum para que todos possam se comunicar mais facilmente. Mesmo que eu nao concorde com um nome, eu procuro saber o que ele significa para outros profissionais… e tento explicar também como eu interpreto esse nome.

2 - Acho importante debater sobre o que Fowler, Evans (e outros) escreveram, assim podemos formar nossas própŕias opiniões… Assim também podemos conhecer algo que é mais difundido do que nossas opiniões. Se alguem concorda com tudo que eles escreveram, pelo menos estão concordando com alguem que já refletiu bastante sobre os assuntos…

3 - Nossa “obrigação” é saber a teoria, mas na hora de por na prática saber decidir o que utilizar dela… por exemplo: todos deveriam conhecer o conceito de Repositorio mesmo que nunca venham a implementar…

Acho que a discussao aqui acontece mais porque não existe uma verdade absoluta, porque cada um tem suas opiniões, interpretações e principalmente EXPERIÊNCIAS…

Talvez uns achem Repositorio algo extremamente importante e talvez outros não tenham sentido necessidade de usar. Não podemos esquecer que aqui temos pessoas de todos os tipos…

#77

Concordo plenamente!

(post sem utilidade nenhuma na discussão, mas fiquei muito feliz por alguém ter escrito isso)

#78

Antes que eu me esqueça de novo:

Free book: Domain Driven Design Quickly

[]'s

Rodrigo Auler

#79

Eu acho teoria importante, mas acho tb que um código/exemplo prático fala melhor do que 10 teorias:

Abaixo tenho o modelo:

Action -&gt Model/Manager/Repositório/??? -&gt DAO -&gt Impl DAO -&gt Banco

   public String add() throws Exception {
      
      String method = input.getProperty("method");
      
      boolean isPost = method != null && method.equalsIgnoreCase("post");
      
      if (isPost) {
         
         // post = tentando inserir...
         
         Job job = input.getObject(Job.class);
         
         int id = jobManager.insertJob(job);
         
         if (id &lt= 0) return ERROR;
         
         stageManager.createDefaultStages(id);
         
         return SHOW;
         
      } else {
         
         // get = assume está querendo adicionar um registro...
         
         return SUCCESS;
      }

   }

Será que assim ficaria melhor:

   public String add() throws Exception {
      
      String method = input.getProperty("method");
      
      boolean isPost = method != null && method.equalsIgnoreCase("post");
      
      if (isPost) {
         
         // post = tentando inserir...
         
         Job job = input.getObject(Job.class);
         
         int id = job.insert();

         if (id &lt= 0) return ERROR;
         
         job.createDefaultStages();
         
         return SHOW;
         
      } else {
         
         // get = assume está querendo adicionar um registro...
         
         return SUCCESS;
      }

   }

  • Será que a action deveria acessar o DAO diretamente?

  • Será que minha action virou o modelo?

  • Será que a action deveria virar modelo?

  • Será que o modelo deveria ser separado da action, mas poderia virar uma action não acoplada ao framework? (POJO ACTION)

  • Estou começando a achar que a maneira mais bonita, de forma que sua aplicação ficaria o mais independente possível do framework em questão é:

framework mvc -&gt Modelo/Pojo Action -&gt DAO / Repository -&gt Implementação de DAO -&gt Banco de dados…

Assim vc teria uma action, que não seria na verdade uma action, mas sim uma espécie de model… O preço a pagar me parece claro tb: burocratização do processo… Seria como programar sem uma interface DAO e tentando deixar sua aplicação independente de banco de dados… (Model não é como DAO, não dá para fazer uma interface UserAction, ou seja, para abstrair o modelo de negócios…)

A dúvida que ainda tenho e se realmente vale a pena jogar o DAO pra dentro das entidades e deixá-las o mais esperto possível (segundo código postado) ou trabalhar com Entidades que apenas são envelopes de dados a a manipulação dessas entidades acontece por fora delas via DAO (primeiro código postado)…

#80

[quote=pcalcado]
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.[/quote]

Eu entendi. Só não enxergo nenhuma situação em que usar Repository num objeto de negócio em vez de DAO seja efetivamente vantajoso, na pratica. No fim, da na mesma. :slight_smile: