Filipe, você se preocupa muito com banco de dados!
Estude um framework de persistência ORM e você verá que nunca mais precisará desenvolver um banco de dados.
Abraços
Então
Em minhas aplicações eu uso o hiberbante mais alguns outros patterns como DAO e etc …
Pelo oque ouvi dizer, frameworks de persistencia ORM não são aconselhaveis para uso em aplicações complexas.
Tipo, voce teria alguma dica de um framework de persistencia ORM ? O hibernate não seria um !? Se sim, como não me preocupar com o banco de dados?
[quote=_filipe]Se fizer algo parecido com o citado acima, eu vou ter tantas tabelas no meu banco de dados … que vai ser complica disso manter …
[/quote]
por isso que você não vai manter. Você vai deixar algum framework manter.
Afinal vc está fazendo java ou programação-de-banco-de-dados-disfarçado-de-java ?
Entao, quando quiz dizer manter, não foi pensando na aplicação, e sim no banco de dados.
Realmente, estou preocupado com o banco de dados, pois estou pensando em objetos e no mapeamento do mesmo com as tabelas do meu banco. (É errado pensar assim?)
abras
O que seriam aplicações complexas? Particularmente, eu nunca ouvi falar dessas limitações do Hibernate. Mas não posso falar que já vi aplicações críticas utilizando-o.
Sim, o Hibernate é um exemplo.
Não é que você não tenha que se preocupar com o banco, e sim, você não precisa se preocupar em desenvolvê-lo. Você constrói o seu modelo utilizando suas classes e se preocupa apenas com ele. Modificações que por ventura venham a ser necessárias no seu modelo refletirão diretamente no banco de dados.
Uhnm … entendi
beleza
valeu galera
Veja este livro excelente sobre Hibernate (um dos autores é o criador do framework, Gavin King).
Abraços
Sempre fiz da seguinte maneira.
Faz uma classe Pessoa com (Id, Nome, DtRegistro, Endereco endereco, Telefone[] tel) dai por herança(extends) vc faz sua PessoaFisica e PessoaJuridica.
dai no hibernate vc mapeia a PessoaFisica e PessoaJuridica, como elas estão herdando as propriedades de Pessoa o hibernate já reconhece os atributos.
Na minha opinião, uma interface ou implementação chamada simplesmente “Pessoa” só deveria existir em um sistema, se existir uma entidade chamada ExtraTerrestre ou Animal que possa entrar em conflito de comportamento com a tal “Pessoa”.
Pessoa é algo muito genérico, posso estar enganado mas fatalmente essa modelagem possa ser modelada ao ponto de ficar mais clara.
Com todo respeito e sem querer causar polemicas, vejo muita gente se preocupando em generalizar o maximo seu DAO, estudando afoitamente hibernate e o pior de tudo se gabando por estão programando em poo. Novamente não quero causar polemica pelo contrario, onde eu quero chegar é que existe uma lacuna enorme entre uma modelagem bem feita e o uso de framework e conceitos ddd. Vejo professores de faculdade usando o exemplo de pessoafisica herda pessoa e pseesoajuridica herda pessoa e na próxima aula mostrando hibernate e o conceito de DAO(que é outro ?erro? pois não vejo vantagem em ter um DAO com hibernate já que o mesmo pode fazer o papel do de DAO, a menos que não tenhamos um SGDB e sim um outro mecanismo de armazenagem de dados, bom mas isso é um outro assunto), se um professor usa esse exemplo de modelagem ?ridícula?, não precisa nem ensinar DAO.
Voltando ao problema, acho muito importante debatermos o assunto desse tópico pois não vale nada usarmos poo sem ter uma modelagem apropriada. Minha humilde opnião:
1 não existe pessoafisica e nem pessoajuridica
2 existe sim Pessoa, pense em pessoa como um ser humano
3 existe sim empresa, pense em empresa como um prédio(parece obvio)
4 Esqueça cpf e cnpj como conceito que separam uma pessoa de uma empresa, o que separa uma pessoa de uma empresa é o fato de pessoa ser uma pessoa, ou melhor ter ou não comportamento diferente de uma empresa. A outro detalhe cpf e cnpj são identificações somente aqui no Brasil, mais uma razão para esquecer pf e pj.
A melhor maneira, acho, é começar a modelar pela utilização de pessoa ou empresa dentro do sistema. Bom seu sistema é de venda, então seu sistema terá um cliente, cliente terá um comportamento certo, daí pergunto, qual a diferença quando na loja que usa o sistema o cliente que compra ser uma pessoa ou uma empresa?
Se nenhuma, então simplesmente crie uma interface cliente, daí crie uma person que implementa cliente. Para saber se a person é uma pessoa ou uma empresa crie um método person.isEmpresa. daí aqui não teremos a classe pessoa e nem empresa, mto menos PJ e PF.
Agora se sim, existe diferença entre uma pessoa compra ou uma empresa(lembrando que quem compra é um cliente), por exemplo, o calculo de desconto de uma empresa é diferente de uma pessoa a sim crie duas classes. Empresa implementa cliente e Pessoa implementa cliente. Para venda não importa se cliente é ou não empresa, mas para o sistema sim. Daí quando a venda for calcular por exemplo Cliente.meudesconto(produto) vai usar aqui poliformismo e sim fara sentido ter 2 classes, empresa e pessoa. Lembrando novamente que não existe cadastro de pessoa e empresa e sim de clientes, para o sistema dificilmente vai existir o papel de pessoa e empresa e sim cliente.
Acho que minha explicação ficou meio complica, desculpas, bom se esse assunto fomentar, ?posto ? novamente.
Cara vc poderia fazer o Pessoa Juridica herdar de Pessoa Fisica ficaria bem mais interesante e economizaria classes… pq veja uma Pessoa tera: nome, telefone, endereco, data de nascimento, cpf, uma pessoa Juridica tera todos os mesmos atributos e mais razão social, numero de funcionrios, inscrição estadual, etc…
ao meu ver tera um atributo distinto que tem em uma pessoa e nao tera em uma pj o cpf… porem este atributo vc pode generalisar em pessoa dando o nome de codigoPessoa por exemplo em pessoa fisica seria o cpf e em pessoa juridica o cnpj… creio que fazendo uma modelagem assim isto simplificaria seu codigo…
Cara, concordo com tudo o que você disse.
O Transaction Script (managers com regras de negócio que instanciam VOs disfarçados de entidades do Hibernate e chamam os DAOs para persistí-los) é muito difundido, e é impressionante a quantidade de pessoas que acham que essa é a única forma de modelar a camada de negócios em Java. Pois é a única forma que elas vêem em cursos, pós-graduações e em empresas ( claro que existem exceções, mas aqui onde moro eu nunca vi ). Pior, essas pessoas dizem que estão programando OO. Elas mal sabem que separar dados de comportamento não é exatamente OO - e continuam sem saber - porque não estão dispostas a sentar o rabo na cadeira e estudar fora do ambiente de trabalho ou da faculdade.
[DESABAFO MODE=ON]
Vejo muito esse tipo de atitude passiva nos profissionais. Às vezes tento mostrar as outras opções, apontando artigos e livros, mas acabo sendo ignorado. As pessoas dizem: “beleza, depois vou dar uma olhada”, como se tivessem fazendo um favor a mim, e não a elas. :? Pior é quando a gente sugere usar alguma tecnologia nova: inventam mil desculpas, dizem que não têm tempo, que precisam requerer treinamento, etc etc. Depois essas mesmas pessoas começam a vomitar palavras bonitas, dizendo “ah, precisamos aplicar padrões de projeto, etc etc”, e ainda ficam criticando os programadores COBOL que não querem se atualizar :x
Uma das melhores coisas que aprendi aqui no GUJ foi a sempre procurar me manter atualizado. Conviver com “monstros” como o shoes, cv, Maurício Linhares, Luca, e vários outros que não citei, é realmente muito estimulante.
[DESABAFO MODE=OFF]
Não estou criticando o TS. Há situações em que ele é realmente útil e produtivo. Mas quem usa e diz que programa OO precisa mesmo estudar mais um pouco.
[quote=Joaquimnabuco]Vejo professores de faculdade usando o exemplo de pessoafisica herda pessoa e pseesoajuridica herda pessoa e na próxima aula mostrando hibernate e o conceito de DAO(que é outro ?erro? pois não vejo vantagem em ter um DAO com hibernate já que o mesmo pode fazer o papel do de DAO, a menos que não tenhamos um SGDB e sim um outro mecanismo de armazenagem de dados, bom mas isso é um outro assunto), se um professor usa esse exemplo de modelagem ?ridícula?, não precisa nem ensinar DAO.
[/quote]
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.
Calma, calma. Existir existe. São duas figuras juridicas ( do Direito). As leis que se aplicam a uma não se aplicam necessáriamente à outra. ( os principios se aplicam às duas e por isso as duas se chamam pessoa. Mas este conceito de “pessoa” nada tem a haver com “ser humano” ou “individuo”)
Parece, mas não é. Empresa não é um prédio. Empresa são várias coisas. É uma organização de individuos. Por isso que existe uma hirarquia. É uma figura juridica ( do Direito) com responsabilidades, direitos e deveres. Entre outras.
É porque “empresa” é um conceito rico que é necessário uma coisas como um ERP.
Mas estaremos mantando o polimorfismo tendo que identificar o tipo de pessoas que temos. É exacatamente isso que é errado. O ponto é “Não diferencie individuo de empresa”.
Vai sim. Esse é o problema.
A venda gera obrigações para quem vende. Uma delas é entregar o produto, outra é pagar impostos. O imposto retido/pago é diretamente influenciado se o comprador é uma empresa ou não. Se é uma empresa , que tipo de empresa ? Existe muitos detalhes que influenciam no calculo dos impostos ( outro é o proprio produto). E esta é a razão principal de diferencia pessoa individuo e pessoa empresa. No clipper fazia-se assim " if (empresa) { } else { } " esse if está ai até hoje.
É importante fazer uma analise ( separação do todo) para entender o pq das coisas. O detalhe é que as pessoas se esqueçem de fazer a sintese ( aglomeração ordenada das partes). Só depois de vc entender os detalhes vc pode modelar polimorficamente de forma que as duas classes Individuo e Empresa que implementam Pessoa possam ser usadas indestintamente como Clientes, Fornecedores, etc…
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.
[quote=YvGa][quote=sergiotaborda]
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.
[/quote]
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.
[/quote]
O ponto é : Hibernate é uma a implementação do padrão DomainStore. O DomainStore contém um DAO ( no hibernate chama-se dialetos). Logo, o DomainStore é “maior” que o DAO. Ao criar um DAO de hibernate vc está colocando o “maior” dentro do menor. Isso não faz sentido.
Quem usa Hibernate quer não se preocupar com o banco de dados. A menos que a sua aplicação vá comunica com outra tecnologia que não JDBC, então vc não precisa nunca mudar do hibernate. Em tese, vc poderia até criar um dialeto para XML ou qq outra tecnologia. O problema aí é prático porque o Hibernate é baseado no conceito de que se está comunicando via SQL com um JDBC.
Vc usa hibernate com DAO. Otimo. Vc acha que isso é uma vantagem para a hora que tiver que mudar de persistencia. Então o desafio é simples: construa um outro DAO com dados em memoria e tente usa com a sua aplicação. E veja quantas coisas vc tem que mudar além do DAO. Depois crie um DAO para um conjunto de arquivos XML (um por tabela) e veja quanto mudou. Vc vc não mexer uma virgula no codigo acima do DAO, otimo. Vc construiu um sistema de DAO muito desacoplado da persistencia.
Agora o outro lado da pergunta é: Quantas logicas de negocio vc tem no DAO que teve que reescrever nos dois novos daos ? Se vc não reescreveu nenhum, otimo. Vc fez um DAO desacoplado do dominio.
O ponto é: O seu DAO é desacoplado da API de persistencia E do dominio ?
Vc pode realmente mudar de DAO quanto quiser ?
A resposta provavelmente é não a alguma das questões. E por isso que usar DAO com hibernate é ridiculo. Vc está se enganando, achando que o fato de ter um objeto chamado XYZDAO o está ajudando. Não está.
Concordo com YvGa… criar um DAO do hibernate parece redundante, mas quando for trocar (se for) de framework de persistencia, então é bem mais simples se o Hibernate estiver somente no DAO… se for espalhado pela 100 classes de sua aplicação é mais complicado não?
Quanto ao foco do fórum, apesar de ler tudo, ainda não consigo sair do pensamento da arquitetura:
Cliente extends PessoaFísica extends Pessoa
Funcionário extends PessoaFísica extends Pessoa
Pessoa Jurídica extends Pessoa
Cliente tem muito atributos em comum com Funcionário, encapsulado em PessoaFísica, PARA NÃO PRECISAR REPETIR. Além, Cliente e Funcionário TÊM outros atributos totalmente diferentes, que justifica a separação das classes.
Pessoa Jurídica também compartilha atributos de Pessoa, mas possuem outros tbm diferentes. No caso PJ é meu fornecedor.
Lembrando que Pessoa dita não é “ser humano”, mas sim juridicamente.
Dito isto, como seria um mapeamento mais correto sobre isso? Alguém aí disse que seria legal uma classe para todos, o que mata os atributos que seria repetidos, mas e os atributos diferentes, como faz?? E a regra que diz que uma classe têm que ter todos os seus atributos pertinetes não existe mais??
Abstraindo o real para o lógico, PJ e PF são diferentes, o que não podem existir em uma única entidade. E para não precisarmos repetir atributos e métodos, abstraimos para uma classe Pessoa e extendemos em PF e PJ… não vejo outra solução.
Alguem pode esclarecer melhor?
jopss
Só lhe digo que herança não foi feita para aproveitar campos. Isso é POG.
Herança é utilizada quando existe uma relação É-UM entre os objetos e não quando "TEM-OS-MESMO-CAMPOS"
Enquanto não entender isto, toda a conversa é inutil.
Não, não são diferentes. Se vc não vê isso é porque ainda não abstraiu o suficiente.
sim, falei de REPETIÇÃO para entendimento melhor, pois uma dos conceitos é a abstração. Além:
Cliente É-UMA PessoaFísica É-UMA Pessoa
oq poderia ser feito melhor ae?
[quote=jopss]sim, falei de REPETIÇÃO para entendimento melhor, pois uma dos conceitos é a abstração. Além:
Cliente É-UMA PessoaFísica É-UMA Pessoa
oq poderia ser feito melhor ae?
[/quote]
Muitas coisas.
Cliente não é uma PessoaFisica porque tb pode ser uma PessoaJuridica. Se vc quer melhorar
vc pode dizer que Cliente é sempre uma PessoaJuridica que pode ser um Individuo, uma Empresa, uma Perfeitura, uma Fundação , etc… Vc está dividindo entre fisica e juridica, por vc está dividindo entre cpf e cnpj , mas perfeituras não têm cpf nem cnpj e mesmo assim podem ser clientes. Fundações idem.
Se vc gosta de limitar quem pode ser cliente, vá em frente, mas não é certo.
Somente para colocar lenha na fogueira.
Ainda bem que essa discussão sobre DAO não aflorou novamente, não porque aqui não é o tópico indicado, mas pq é esquisito, as pessoas não conseguem nem abstrair o ?paradigma? pessoa, cliente … e querem abstrair um DAO genérico suficiente para que em uma determinada fase da vida do projeto mude o framework de persistência. Bom a questão alem da já colocada pelo Taborda é: se hj na comunidade java existe dificuldade imensa para abstrair coisas cotidianas, pq alguém acha que vai conseguir abstrair algo tão mais complexo. Logo concordo com Taborda, usar DAO pensando em um dia trocar de framewk de persistência é perda de tempo, é melhor perdemos tempo em discutir coisas como pessoa, cliente e afins, pois existe mais confusão nesse tipo de implementação do que em um DAO que não faz sentido.
Quando comecei estudar POO, principalmente aqui no guj, li mto sobre DAO, alias, contem quantos tópicos sobre DAO existe aqui, hj graças a ajuda o Taborda enxergo que perdi mto tempo de leitura, e pior de programação pois tambem já tentei generalizar um DAO que continha o hibernate. Agora me pergunto, quantos outros conceitos estão sendo difundidos aqui em outros sites e que não fazem sentidos.
Sou programador Delphi e C#, a pouco tempo(1 ano) comecei a programar em java, escutei muitas coisas como ?programador Delphi são apertadores de parafusos ?.. ? ahh eu programo em java e sou o cara ? … ?ahh eu programo em java logo programo em POO?. Sim o guri começa a programar em java faz uns new alguma coisa, lê sobre DAO hirbernate e pronto acha que sabe td, vira um cético ignorante e fica difundindo coisas sem nexo. Desculpe meu desabafo mas vejo o mesmo numero de bobagens nos fóruns de delphi e java, a diferença é que em fóruns java existe mto mais pessoas que realmente sabem, e diga-se de passagem, são mto mais participativos.
Desculpe ter fugido do assunto, bom, se esse tópico pelo menos consegui-se deixar claro que começar a abstrair pessoa pelo cpf e pelo cnpj é ridículo eu já fico feliz.
Quando digo que pf e pj não existe, realmente estou me expressando mal, mas oq quero passar é que começamos abstrair através de outro ponto, e não pela mera diferença de campos como cpf e cnpj.
Agora vejamos a confusão, não conseguimos chegar em uma conclusão como seria melhor abstração de pessoa, cliente … e alguns querem discutir generalização sem fundamento de um DAO. Vamos concluir e chegar em um veredito sobre o assunto proposto pelo tópico em depois discutir o maldito DAO.
Acho q um grande contribuidor para essa confusão de pj, pessoa … são os exemplos didáticos, já li livros vários livros, alias quase todos exemplos de poo onde se apresenta o exemplo: PF herda pessoa e PJ herda Pessoa. Começa-se ensinar poo através de herança quando deveria-se começar por interface composição. Eu sou um hibrido desses livros e professores que tiveram a infelicidade de usar esse exemplo.
Então como idéia vamos começar pensar na idéia de cliente. Quem é o cliente oq ele faz, oq ele pode, que pode ser o cliente.
Daí vamos criar uma interface cliente e depois voltar para discussão pessoa e esquecer pf e seus atributos.