Pois é. Eu pensei isso tb quando vi o post do Sérgio (não lembro se foi ele que falou) que está cansado de ver service como delegate dao. Pensei que talvez isso fosse feito pensando na possibilidade de colocar uma lógica futuramente.
Mas é isso então, cara.
Sinto que nessa thread eu passei de não saber nem o que é service pra entender muito bem (na medida do possivel, né? pq nem apliquei ainda), como e quando utilizar.
Muito obrigado, Rodrigo. Obrigado mesmo!
E muito obrigado a todos!
[quote=Rodrigo Sasaki][quote=Kura]Pra mim, se eu uso service em uma por necessidade, fica mais legível colcar o service em todos os outros casos. Mesmo que alguns deles sejam apenas para delegar dao.
Mas… eu sempre quero saber as melhores práticas, né? As vezes eu acho isso e não tem nada a ver =x[/quote]
Eu concordo com você.
Ainda mais se você não estiver desenvolvendo sozinho, imagine que você tem uma equipe. Entra uma pessoa nova e ela vê esse padrão em uma tela. Controller > Service > DAO.
Aí em outra situação a pessoa analisa uma outra funcionalidade e vê o DAO injetado direto no Controller. É claro que funciona, mas isso pode confundir, manter o padrão é sempre bom (na minha opinião).
Outra situação:
Imagine que um service é um mero delegate pra um DAO, e por algum motivo, é decidido que a regra de negócio ali tem que mudar, você precisa acessar mais tabelas, fazer mais consistências e etc. Só aí vai criar o service? E depois vai substituir todas as chamadas ao DAO para chamadas ao Service? Manter o padrão nesse caso também vai facilitar a manutenção do seu sistema.[/quote]
Eu tinha dado uma opinião contrária,mas preciso concordar com vc.
[quote=Kura]
Sinto que nessa thread eu passei de não saber nem o que é service pra entender muito bem (na medida do possivel, né? pq nem apliquei ainda), como e quando utilizar.![/quote]
Quero aproveitar para deixar um elogio para esse tópico.
Uma discussão saudável, simples e informativa com um resultado excelente: pelo menos 2 pessoas abriram a mente para novas maneiras de pensar em organização e qualidade do código.
Queria que as pessoas que desenvolveram o sistema que estou dando manutenção hoje tivessem lido isso! kkkkk
É sério, estou vivendo na prática as consequências de se achar que as regras de negócio não precisam ficar isoladas, pois o sistema “é simples”. Agora o sistema cresceu, existem diversas funcionalidades que usam as mesmas regras e elas estão replicadas em todos os pontos. Fora que algumas regras estão na apresentação (controller) enquanto outras estão no DAO, dependendo de quem foi mantendo ao longo do tempo!
Parabéns ao Sérgio e ao Rodrigo, pois explicaram bem os problemas envolvidos nessa decisão ao invés de simplesmente tentar impor por ser padrão.
[quote=gomesrod]Quero aproveitar para deixar um elogio para esse tópico.
Uma discussão saudável, simples e informativa com um resultado excelente: pelo menos 2 pessoas abriram a mente para novas maneiras de pensar em organização e qualidade do código.
Queria que as pessoas que desenvolveram o sistema que estou dando manutenção hoje tivessem lido isso! kkkkk
É sério, estou vivendo na prática as consequências de se achar que as regras de negócio não precisam ficar isoladas, pois o sistema “é simples”. Agora o sistema cresceu, existem diversas funcionalidades que usam as mesmas regras e elas estão replicadas em todos os pontos. Fora que algumas regras estão na apresentação (controller) enquanto outras estão no DAO, dependendo de quem foi mantendo ao longo do tempo!
Parabéns ao Sérgio e ao Rodrigo, pois explicaram bem os problemas envolvidos nessa decisão ao invés de simplesmente tentar impor por ser padrão.[/quote]
Ah, eu sei bem como é isso. Na verdade é realmente complicado entender os padrões até você dar de cara na parede igual você está fazendo agora (ou igual eu já fiz também).
Já passei por uns projetos que nem pareciam que utilizavam uma linguagem orientada a objetos 
Você por ter bastante experiência já entende que essa complexidade a mais vai te poupar muitas horas de trabalho e dor de cabeça.
Agora com certeza o Kura vai passar por situações parecidas (como todos nós passamos, não é mesmo?), e vai ver as vantagens e desvantagens de cada decisão tomada.
[quote=Rodrigo Sasaki][quote=gomesrod]Quero aproveitar para deixar um elogio para esse tópico.
Uma discussão saudável, simples e informativa com um resultado excelente: pelo menos 2 pessoas abriram a mente para novas maneiras de pensar em organização e qualidade do código.
Queria que as pessoas que desenvolveram o sistema que estou dando manutenção hoje tivessem lido isso! kkkkk
É sério, estou vivendo na prática as consequências de se achar que as regras de negócio não precisam ficar isoladas, pois o sistema “é simples”. Agora o sistema cresceu, existem diversas funcionalidades que usam as mesmas regras e elas estão replicadas em todos os pontos. Fora que algumas regras estão na apresentação (controller) enquanto outras estão no DAO, dependendo de quem foi mantendo ao longo do tempo!
Parabéns ao Sérgio e ao Rodrigo, pois explicaram bem os problemas envolvidos nessa decisão ao invés de simplesmente tentar impor por ser padrão.[/quote]
Ah, eu sei bem como é isso. Na verdade é realmente complicado entender os padrões até você dar de cara na parede igual você está fazendo agora (ou igual eu já fiz também).
Já passei por uns projetos que nem pareciam que utilizavam uma linguagem orientada a objetos
Você por ter bastante experiência já entende que essa complexidade a mais vai te poupar muitas horas de trabalho e dor de cabeça.
Agora com certeza o Kura vai passar por situações parecidas (como todos nós passamos, não é mesmo?), e vai ver as vantagens e desvantagens de cada decisão tomada.[/quote]
Rapaz…
Estou há menos de 3 meses trabalhando profissionalmente com JAVA, mas, antes disso, eu trabalhei quase 3 anos com vb3!!!
Foram tempos obscuros, cara. Sério. Num determinado dia eu recebi a notícia de que “a quantidade de digitos da nota fiscal iria mudar”. Acrescentar 3 dígitos, sabe?
Numa empresa que tem vb3 como linguagem domintante… e que tem mais de 130 sistemas!! E cada view de TODOS os sistemas tinha varios format(“000000”)!
Ou seja formats * views * sistemas.
Fiquei meses fazendo isso.
Por mais que eu não tenha xp nenhuma com JAVA, eu entendo muito bem que decisões tem consequências.
Talvez por isso tenha desenvolvido esse perfil de procurar sempre a melhor forma de fazer e não só aceitar o que está ali e copiar.
huahuahuhauhahuhah
[quote=Kura]Então eu posso ter, no mesmo sistema, dao sendo injetado em um objeto da camada de apresentação (pq eu não terei lógica de negócio) e, num outro obj de apresentação eu trabalhar com service?
não há questões com relação à boas práticas?[/quote]
Eu queria focar neste ponto de ser permissivel que em alguns pontos o dao seja injetado diretamente ou que alguns services são apenas delegates para o dao.
A primeira coisa é: se o seu service é apenas um delegate, o seu sistema está errado.
Peguemos o exemplo clássico do save. A apresentação chama o save do service que chama o save do dao. A apresentação montou o objeto e enviou. Quem está garantindo que o save pode ser feito ? quem está validando ? quem abriu a transação ? não ah transação ?
O service precisa validar. E só por isso a responsabilidade do service já é diferente da do dao. Isso faz com que código que apenas delegam sejam sinal de que falta alguma coisa no código.
O outro lado da moeda é fazer uma pesquisa. O famoso listar. A UI monta o filtro e passa para o service que delega ao dao. O dao retorna o resultado e vem tudo para cima até à ui.
Bom, em tese poderíamos validar o filtro. Isso é raro, mas às vezes é necessário. Mas fora isso não ha muito a fazer. Aqui realmente parece que apenas ha uma delegação. E de fato é isso mesmo. Está errado ?
Não está errado. As camadas foram desenhadas assim. A camada de apresentação não deve enxergar a camada de integração (Dao) ela só vê a camada de dominio (Service).
A pura e simples delegação é oca. É quase uma violação do DRY. Será possivel desenvolver de outra forma, para que não seja necessária a delegação ?
Sim. Basta adicionar à camada de domínio uma outra classe que esteja no mesmo nivel do service, que a ui possa acessar, mas que não é um service. Esse padrão é o Repositório. Por baixo em algum ponto pode estar o DAO ou outra coisa qualquer, mas do ponto de vista da UI o dao simplesmente não existe. Se corresponde ao cliente saber que existe um banco de dados. Ele simplesmente não deve saber disso.
Portanto, existe outras técnicas e padrões que realmente se ajustam melhor do que o design ui > service > dao, mas se o design já está fixo nesse padrão, então realmente vai aparecer um pouco de delegação.
Sendo que ela está lá, é válido pular a camada de service e ir diretamente no dao ? Não. Isso viola a separação de camadas. Cada camada só conhece a que está imediatamente abaixo. Não conhece a de cima e não conhece as mais abaixo que a seguinte. Porque alguem iria violar este principio ? Simplesmente não é saudável tentar.
A única maneira de driblar este problema é introduzir o conceito de repositório, mas isso significa sair do design ui> service > dao e pode ter implicações de o sistema é distribuído.
Obrigado, Sergio.
Foi um post bastante informativo e me ajudou a solidifcar ainda mais os conceitos.
Ainda me serviu de ancora para pesquisar e entender mais sobre o Repositório.
Grande abraço!
no final das contas isso vai depender do arquiteto/líder técnico responsável pelo projeto.
mas aqui no meu atual emprego foi onde vi uma arquitetura mais coerente, temos de maneira bem isolada:
camada de apresentação: JSF
camada de persistencia: beans
camada de Negócio: EJBs
as coisas estão bem separadas.
São tópicos como esse discutindo o sexo dos anjos que ajudam a criar essas monstruosidades.
É o que estava falando em um outro tópico.
Você pode usar a melhor linguagem e contratar os melhores programadores OO, mas se o profissional não conhece o domínio do sistema que está desenvolvendo (como a maioria que opinou nessa thread) não será capaz de chegar a uma solução elegante, porque lhe falta visão sobre o problema.
Pessoal achei esse tópico muito interessante.
Estou migrando para o java EE e gostaria de saber se eu entendi corretamente o que os amigos explicaram.
(1) VIEW (JSF) -> (2) CONTROLER-MB(CDI) -> (3) SERVICE (EJB - @Stateless/@Statefull) -> (4) DAO (EJB - @Stateless/@Statefull)
TRATAR AÇÕES DO JSF, CICLO DE VIDA ETC.
SE NECESSÁRIO MIGRAR PARA OUTRA TECNOLOGIA BASTA CRIAR OUTRA CLASSE SEM ALTERAR O RESTANTE DO FLUXO.
REGRA DO NEGÓCIO VALIDAÇÕES ETC.
PODE TER DAO PARA OPERAÇÕES QUE UTILIZAM BANCO DE DADOS.
OPERAÇÕES QUE UTILIZAM BANCO DE DADOS.
É isso?
Grato.