Não estou sugerindo abolir os identificadores. Estou afirmando é que os identificadores são uma solução específica para infraestrutura e não para negócio. Por isso não deixa de ser um bad smell ficar passando os identificadores como parâmetro para metodos no domain.
No entando concordo quando o Phillip diz:
Mas repare que mais uma vez o motivo de precisar usar o buscaPorId foi porque ou a apresentação exige ou a infraestrutura exige. Existem exceções claro, mas eu nunca disse que não existe. =)
Primeiro, obrigado pela sinceridade. É sempre bom saber o que estão pensando dos nossos posts. Você pode ter razão, mas eu pedi desculpas antecipadamente. Além disso eu afirmei que não li TUDO que haviam postado. Mas li o tópico inicial e alguns outros posts. Não tenho essa mesma certeza de que piorei muito a qualidade do debate. Pelo contrário, acabou surgindo um tema que pode aperfeiçoar em muito o conhecimento de todos que estão lendo. Ou estou errado?
Identificadores existem em muitas situações de negócio.
Novamente, não é excecao. Muitas vezes identificadores estão contemplados de alguma maneira no negócio.
Independente disso, ja que voce nao ve sentido em usar ids no repositorio eu gostaria de saber o que voce faria nesses casos onde se trata apenas de exigencia da apresentação/infra. Nao podemos esquecer que apesar de repositorios fazerem parte do dominio eles existem mais para suportar o dominio do que efetivamente agrupar regras de negocio.
[quote=cmoscoso][quote=feliperod]
Não estou sugerindo abolir os identificadores. Estou afirmando é que os identificadores são uma solução específica para infraestrutura e não para negócio. Por isso não deixa de ser um bad smell ficar passando os identificadores como parâmetro para metodos no domain.
[/quote]
Identificadores existem em muitas situações de negócio.
Novamente, não é excecao. Muitas vezes identificadores estão contemplados de alguma maneira no negócio.
Independente disso, ja que voce nao ve sentido em usar ids no repositorio eu gostaria de saber o que voce faria nesses casos onde se trata apenas de exigencia da apresentação/infra. Nao podemos esquecer que apesar de repositorios fazerem parte do dominio eles existem mais para suportar o dominio do que efetivamente agrupar regras de negocio.[/quote]
A resposta é simples como citado pelo próprio Phillip em alguns posts acima.
Só certifique-se se o ID é realmente necessário pelo negócio e não apenas porque tem ua URL que recebe o ID como parâmetro e vc não sabe mais como buscar algo. O importante é ter BOM SENSO. Não precisa criar uma parafernalha desnecessária, mas pode pensar em uma forma prática de resolver isso, partindo dos conceitos de Query Object e outros patterns. Claro, isso se quiser e puder usar DDD.
Na hora que inclui este ID estava pensando em como eu pego dados de um repositório qualquer em memória que implemente a interface “List”. myArrayList.get() - claro que a posição com o ID não tem nada ha ver -em momento-, mas ficou bom e fácil de buscar um bean pelo identificador ! Mas como pode ser visto, o ID é genérico, então pode ser um hashcode, a posição realmente dele em alguma lista ou any.*… tudo vai depender do seu negócio.
Exatamente. Você está correto. Entendeu minha mensagem. Usou de Bom Senso. Mas vale lembrar que substituir o ID pelo hascode não resolve essa questão. Hashcode é apenas uma técnica para tratar objetos e não entidade de negócio.
Acho que a pergunta real é: O que faz de um objeto uma entity? Essa pergunta não é retórica e acrescentaria uma contribuição gigantesca se for respondida.
Bom, como a brincadeira da [EDITADO POR ALGUM MODERADOR …] acabou vou colocar a minha resposta pra meu desafio com o intuito de contribuir. Aliás até o desafio foi apagado então vou simplesmente postar a minha definição de uma entity:
Pra mim uma entity deve ser criada para representar um conjunto de dados únicos que, unidos não se repetem no sistema. Por isso não considero somente a identidade como um código numérico ou de qualquer espécie como uma definição de negócio. Na verdade eu acredito que o código numérico existe apenas para evitar que usemos vários dados ao invés de apenas 1.
Por exemplo, uma pessoa normalmente é uma entity, porque o conjunto é único. Um nome pode se repetir, um endereço pode ser o mesmo para duas pessoas, porém o conjunto. (Endereço, Nome, Telefone, Idade, Numero de Cueca, etc…) não se repete. Pra mim isso é a idedntidade. Esse tipo de situação é que define uma entity.
Bom, aí está minha contribuição.
Espero que isso também não seja [EDITADO]. A liberdade de expressão foi pra puta que pariu agora.
[quote=feliperod]Bom, como a brincadeira da [EDITADO POR ALGUM MODERADOR …] acabou vou colocar a minha resposta pra meu desafio com o intuito de contribuir. Aliás até o desafio foi apagado então vou simplesmente postar a minha definição de uma entity:
[/quote]
[quote=feliperod]
Espero que isso também não seja [EDITADO]. A liberdade de expressão foi pra puta que pariu agora.[/quote]
Não é brincadeira, Felipe, você foi avisado e tornou a repetir o erro. Boa parte das pessoas do GUJ trabalha para ou possui empresas de trinamento ou ferramentas e é obrigação da moderação não deixar o fórum virar propaganda. Sua liberdade de expressão está assegurada, assim como a liberdade do usuário em ter um fórum livre de propaanda não-solicitada.
Além do mais, liberdade de expressão pressupõe respeito com palavras então peço para que guarde seus palavrões para um lugar mais apropriado.
poxa pessoal. pensem no peerless, se eu estivesse no lugar dele, estaria puto. gostaria de um diálogo construtivo. não sou moderador mas vamos deixar essa conversa mole para uma mp. critiquem-se entre si via mp. fico interessado com as idéias e toda vez quando volto para este post, só vejo decepção. me desculpe mas eu tinha que falar isto.
[quote=sergiotaborda][quote=wagnerfrancisco]Então usando Hibernate a presença dos DAOs é dispensável, correto?
[/quote]
Sim.
[/quote]
Divergência detected.
Vc acha que um GenericDAO pode suprir todas as necessidades de todo o seu sistema só por usar Hibernate?!
E as queries especializadas? E as regras aplicadas em banco?
Acho muito pouco provavel que isso aconteça na vida real, tendendo a zero!
[quote=rodrigoallemand][quote=sergiotaborda]
Repository = UsuarioRepository
DAO = UsuarioDAO
Implementação do DAO = JDBCUsuarioDAO (note o nome da tecnologia de persistencia no nome)
[/quote]
[quote=sergiotaborda][quote=wagnerfrancisco]Então usando Hibernate a presença dos DAOs é dispensável, correto?
[/quote]
[quote=sergiotaborda][quote=wagnerfrancisco]Então usando Hibernate a presença dos DAOs é dispensável, correto?
[/quote]
Sim.
[/quote]
Hibernate não é sinônimo de qualidade nos DAOs.Também não é indispensável.
[quote=rodrigoallemand]
Divergência detected.
Vc acha que um GenericDAO pode suprir todas as necessidades de todo o seu sistema só por usar Hibernate?!
E as queries especializadas? E as regras aplicadas em banco?
Acho muito pouco provavel que isso aconteça na vida real, tendendo a zero![/quote]
É possível um GenericDAO suprir muitas necessidades da sua aplicação. Já participei de situações em que um DAO genérico atendia 100% dos casos, com Hibernate. Também já criei DAOs com BoxSQL que atendem boa parte das situações, já que é possível passar quase tudo por parâmetro para um template, inclusive uma clausula where. Com Hibernate ou JPA, pode criar NamedQueries para resolver a questão de queries customizadas.
Se FISICAMENTE quer dizer que não precisa de uma implementação dentro do domain, está certo. Há casos em que podemos ter uma interface como repository que expressa os conceitos de negócio, mas a implementação fica na camada de infra-estrutura.
Feio é, mas isso não é limitação sua. É limitação da tecnologia. Organização de metainformações em java não é muito elegante. MAs pode usar o BoxSQL ou mesmo as NamedQuery do Hibernate. Mas eu prefiro o BoxSQL. (Aliás, vai um link aí pra página do projeto. que tá mudando de casa. O Java net é meio confuso na parte de iteração com os participantes.)
Bem, se uma hora vc fala que DAOs implementados necessitam da prefixação da tecnologia utilizada, como alguns posts depois vc confirma para o owner do tópico que, em se usando Hibernate, o DAO é dispensavel?
Remetendo a sua afirmativa de HibernateDAO desnecessário, a unica alternativa de vc acessar algum tipo de dado seria usando-se um DAO genérico, compartilhando-o para todas as entidades, certo? Ou vc pretende fazer isso de outra maneira que não as vias normais?
Vc acha que o seu dominio e o seu banco vão ser sempre tão perfeitos que vc nunca precisará de uma especialização no acesso aos dados, ou vc sempre coloca essas informações no repositorio… Pense grande, e não em sisteminhas… em sistemas complexos vc vai precisar de um recurso de banco para livrar o seu dominio, seja por performance, seja por ineficiencia da linguagem/framework, etc.
Só pra alinhar o debate, eu sou de acordo com a estrutura que vc propos, só não entendi quando vc colocou que o Hibernate é unipresente para DAOs, independente da entidade.
[quote=rodrigoallemand][quote=sergiotaborda]
Não vejo onde…
[/quote]
Bem, se uma hora vc fala que DAOs implementados necessitam da prefixação da tecnologia utilizada, como alguns posts depois vc confirma para o owner do tópico que, em se usando Hibernate, o DAO é dispensavel?
[/quote]
Com DAO hibernate é dispensável. Sim. Logo, não faz sentido escrever HibernateDAO.
Quando me refiro a DAO genérico me refiro do ponto de vista que ele e independente do dominio , da entidade, etc… não que ele é independete da tecnologia de persistencia. Isso seria uma antitese do proprio padrão.
Continuo sem entender muito bem o que pertende levantar com a sua interrogação. Não sei se a explicação acima é suficiente.
Se não for , explique mais detalhadamente o seu ponto.
Se vc entender “normal=usar hibernate” então sim. DAO não deve ser implementado usando hibernate : isso é um facto. Se vc não o aceitar vc vai ter problemas na arquitetura. Mas lembre-se que DAO é diferente de Repositorio e normalmente quando se usa hibernate já se usa Repositorio por padrão, já que instintivamente vc encapsula o acesso ao hibernate em outra classe. Só que essa classe não e´um DAO, é um repositorio. Numa arquitura com Hibernate o DAO está dentro dele ( é o Dialect)
Um DAO genérico é aqule que vc implementa uma vez e usa em todas as aplicações independetemente do dominio.
Vc pode pensar que Hibernate é a unica forma de alcançar isso, mas não é.
Exactamente por isso não se usa Hibnernate. Usa-se DAO. E sim é possivel sempre abstrair qualquer tipo de acesso porque afinal não existem tantos assim ( SELECT, INSERT , DELETE , UPDATE). Problemas de performance não são responsabilidade do DAO.
Contudo vc pode usar alguns padrões como o Fastlane para ajudar. Se a querie é muito complexa o repositorio dá conta. Mesmo que a tenha que escrever na mão e contornar o DAO (isso não é ideal - poque é uma violação do contrato do DAO - mas funciona).
qualquer tipo de regra de dominio/negocio simples ou especial de acesso a dados não fica no DAO. Fica no repositorio. Logo, por definição, o DAO não contêm nenhuma regra do dominio, e por consequencia ele é genérico.
Pense assim, no Hibernate não existem regras de negocio. Vc utiliza o hibernate para criar as regras. A mesma coisa com o DAO. Ele é independente, desacoplado, reutilizável. Não contêm regras.
[quote]
Só pra alinhar o debate, eu sou de acordo com a estrutura que vc propos, só não entendi quando vc colocou que o Hibernate é unipresente para DAOs, independente da entidade.[/quote]
Não sei ao que se refere. Reli todo o thread enão entendo donde parte a sua duvida.
Nunca falei que o Hibernate é presente nos DAO (unipresente ? o que é isso ? quiz dizer onipresente ?).
Aliás, sempre defendi que: ou vc usa Hibernate ou vc usa DAO. Usar DAO baseado em Hibernate é asneira.
Independentemente de qual usar, vc precisa usa Repositorio, que é onde ficam as regras de negocio.
Tá dificil de entender isso mesmo… bem… vamos por partes… se vc for fazer um sistema hj que utiliza o Hibernate para ORM, vc não teria DAO? Como ficaria então? Explique-se, ai fica melhor de alinharmos um dialogo…
Pelo que entendi, neste caso, então, o repositorio chama alguma classe utilitária do Hibernate que realiza essa transação com o banco, os inserts, selects da vida…seria isso?
