| Autor |
Mensagem |
|
|
|
Todos esses livros sao excelentes. Eu so colocaria como primeiro da lista (na ordem que deveria ser lido) o Applying UML and Patterns do Craig Larman. Ele tem uma traducao em portugues, fraca como sempre, mas nao compromente muito. "Utilizando UML e Padroes" é o titulo em portugues. Apesar do titulo ele é bastante voltado para a analise OO e nem tanto para UML.
|
 |
|
|
reinaldob wrote:Concordo com vc ! 
Todo o caso é que se formos levar OO ao pé da letra, isso seria o correto, pq todos os comportamentos possíveis para a Pessoa estariam dentro da própria classe(mesmo que implementada através de composição).
Eu discordo, segundo OO, isso fere a regra de responsabilidade da classe, que é alguma coisa dentro das regras de negocio. A partir do momento que nela esta contido o codigo de persistencia ela está fazendo mais coisas do que deveria.
Agora, na pratica eu ja nao sei, nunca usei AR e talvez por isso nao vejo suas vantagens.
|
|
|
|
Lezinho wrote:
Se vc ja tem um repositório pronto para receber pessoas como no código acima (que seria um repositório de pessoas), pq aprisiona-lo dentro de uma entidade? No seu caso vc tem uma redundância, um objeto no domínio responsável por armazenar pessoas (repositorio) e um método em um Entity que faz a mesma coisa, onde um apenas chama o outro (isso é, se de fato o repository no código acima é o pattern Repository).
Usar ActiveRecord em Java pode até ser "interessante" em algum tipo de implementação (talvez utilizando instrumentação ou aspecto), mas não apenas dando uma volta ao mundo para chegar de novo no repositório.
Exatamente a minha duvida enquanto eu ia lendo os posts. Ai eu pergunto: segundo a definicao do AR, basta que ele tenha um metodos de acesso, mesmo que por tras usem os repositorios, pra que sejam AR? Pelo que eu havia entendido do padrao é que o proprio objeto continha as regras de persistencia. Estou errado?
|
|
|
|
Ao meu ver so ganharia que nao precisaria ser feito o mapeamento objeto-relacional.
Na verdade essa é a unica razao pra existencia do hibernate e a unica que exige que ele seja usado, mesmo assim é mais do que suficiente pra explicar seu uso.
Se voce esta desenvolvendo algo procedural, que comporta perfeitamente as implementacoes diretas em JDBC, o hibernate na verdade so vai atrapalhar. Se voce esta desenvolvendo OO, pode ate tentar comecar implementando via JDBC, mas logo vai descobrir o quanto é complicado fazer o mapeamento e provavelmente vai procurar uma ferramenta que faça.
|
|
|
|
sergiotaborda wrote:
finalmente alguem que entendeu o problema. É isso mesmo. DAO com hibernate é rídiculo. Pessoa fisica e Juridica como herança de Pessoa é ridiculo. Acrescento também a modelagem de Cliente como herança de Pessoa.
Neste ponto especifico e apenas neste eu discordo do Sergio. O que acontece se amanha surgir um outro super ultra mega framework pra substituir o hibernate? Eu tenho que fazer modificacoes em todos os meus repositorios pra me adequar a ele. Repositorios fazem parte do dominio e devem mudar quando houver mudanca no dominio e nao por outro motivo (mudanca no framework de acesso). Regra basica de responsabilidade: uma classe deve ter uma e apenas uma razao para mudanca.
Eu nao vejo como uma obrigacao de uma boa arquitetura os DAOs quando vc tem o hibernate, mas nao acho que seja ridiculo.
Quanto ao velho problema de pessoa fisica e pessoa juridica vai outro velho conceito OO. Encapsule o que varia. Agora se varia muito nao faz sentido pertencerem a um mesmo conceito so pelo fato de ambas se chamarem pessoa.
|
|
|
|
|
Mesmo com a traduca ruim vale a pena. Acho q eh melhor livro de iniciacao aos design patterns.
|
|
|
|
Ja pelo q eu entendi alguns disseram nem ter lido.
Pra eles terem escrito uma ferramenta como hibernate a experiencia deles deve ser muito grande em DB, ou seja, essa é a especialidade deles, talvez nao tenham tanta assim em arquitetura.
Mas enfim, o problema eh o conceito do Repository q o pessoal perde. Eles reclamam dizendo q eh igual ao DAO e q entao nao ha necessidade. Primeiro q segundo DDD repositorios sao concretos, nao se abstrai, nao tem generico, nem reutilizavel. A responsabilidade dele eh o seu agregate e nada mais. Mudam as regras, mudam os repositorios. Claro q tem muita gente usando eles como DAO, mas nao eh esse o intuito.
Vale lembrar tambem q o Eric Evans sequer menciona o pattern DAO no livro, o repositorio ta la, por tras dele se vc vai usar DAO, Hibernate diretamente, JDBC ou qqr outro pattern q possa surgir, eh opcao sua e nao invalida o uso do repositorio. Repositorio nao eh mecanismo de persistencia, eh objeto de dominio.
Pelo menos foi assim q eu entendi, a nao ser q eu tenha entendido errado, o q nao eh incomun.
|
|
|
|
Só para constar...
Gavin King é o criador do Hibernate. Hoje, ele tem outro filho (o Seam).
Christian Bauer, atualmente, é o maior contribuidor do projeto Hibernate.
Esses caras devem ter alguma razão no que falam, não!?
Entao ta explicado, a praia deles eh outra.
De qqr forma, seja la quem for, nao se deve criticar algo sem nunca ter lido.
|
|
|
|
fabiocsi wrote:
Persistência é um princípio de OO? 
eu disse isso????
Acho q nao. Se foi essa a impressao q passou, me expressei mal. Alias, lendo e relendo nao consegui fazer essa leitura.
|
|
|
|
Vc ta lidando com a parte mais complexa de orientacao a objeto na minha opiniao q eh a mardita persistencia.
O meu conselho e nao tentar reinventar a roda, de uma olhada no pattern DAO, mapeamento objeto relacional, frameworks de persistencia e coisas do genero.
Nao mao eh mto trabalhoso e nao compensa o esforco.
|
|
|
|
O problema do DDD eh q eh visto por muitos como o calice sagrado, aquilo q contem toda a essencia das coisas.
Todo mundo pensa - assim com eu pensei - que ia comprar o livro, ler em uma ou duas semanas e depois ligar pro Evans e pro Fowler pra marcar uma cerveja e discutir o futuro do desenvolvimento de software. E nessa o neguinho quebra a cara.
DDD eh dificil pacas. Nao eh uma descricao de patterns (embora tenha alguns). Ele ensina a vc ficar atento a algumas coisas pra descobrir um design melhor, mas nao te ensina um design melhor pro teu problema (e nao teria como, afinal eh teu problema). Eh dificil, complexo e com exemplos q vc nao consegue facilmente transportar para o seu dia-a-dia. Vc tem q ler e reler e reler e aos poucos vc vai pegando uma coisa aqui e outra ali.
Pelo menos esta sendo assim comigo.
Mas mesmo assim é um livro indispensavel.
|
|
|
|
Clearly, I need to actually read the damn book for myself
Parei de ler nesse ponto.
|
|
|
|
Como sempre o Sergio esta certo.
Eu me pergunto pq as pessoas confundem tanto model-view-controller com arquitetura em tres camadas (apresentacao-negocios-persistencia). Sera q eh pq sao tres? Se vc falar em Huguinho, Zezinho e Luisinho sera q vao confundir tbm com MVC?
Obs: Nada contra quem postou a duvida. Fez mais do q o certo perguntando. E eu mesmo ja vi varios artigos em q existe essa confusao o q aumenta a no na cabeca de quem esta tentando aprender.
|
|
|
|
|
Da uma olhada na tag <component> do hibernate.
|
|
|
|
sergiotaborda wrote:
Se o DAO souber tudo isto, ele contém logica de dominio. E isso, acho que concordamos, é uma violação do padrão DAO.
Qual a necessidade de ter DAO entao? No meu modo de ver sao eles podem ser os responsaveis pela construcao dos objetos e entrega-los aos repositorios ja em estado valido. (Nao q os repositorios nao possam eles mesmos fazer isso), mas como ja disse antes - particularmente prefiro q os DAOs facam.
Tbm discordo Sergio qdo vc diz q os DAOs nao devem conhecer os objetos de dominio, eles fazem parte da camada de persistencia q pode perfeitamente conhecer a camada de dominio - o contrario eh q nao eh aconselhavel. O q nao pode realmente e a persistencia conter logica de dominio, mas transformar algumas linhas de tabelas num banco de dados num objeto na memorio em estado valido nao eh regra de dominio, mas funcao propria da camada de persistencia.
|
|
|
|