| Autor |
Mensagem |
|
|
Existem três maneiras de mapear este tipo de coisa usando annotations do hibernate (que tenho quase certeza, são da mesma maneira em JPA tb)
Table per Class Strategy: the <union-class> element in Hibernate
Single Table per Class Hierarchy Strategy: the <subclass> element in Hibernate
Joined Subclass Strategy: the <joined-subclass> element in Hibernate
De uma olhada aqui: http://www.hibernate.org/hib_docs/annotations/reference/en/html_single/#d0e788
|
 |
|
|
|
Poderia dar mais detalhes? Principalmente de código...
|
|
|
|
Eu não sei eu sou cabeça dura... ou se ninguem consegue me convencer...
Essa idéia de colocar regras de negócio em objetos, pra mim realmente faz muito sentido.
Porém não consigo visualizar uma aplicação WEB ou pior ainda EJB com esta estrutura.
Perguntas:
1: Quase todos os padrões J2EE então são considerados procedurais e não OO? Ou seja todos eles possuem uma péssima modelagem? Grande parte deles são simplemente delegates...
2: Vamos supor a seguinte situação dentro de uma action. (é apenas uma abstração, sei que as actions não recebem estes atributos.
Ou isso:
|
|
|
|
Interessante o artigo... já tinha visto pedaços dele.
Mais voltando um pouco mais... Olhando para os padrões GRASP, o padrão Controller então não é OO? Já que pelo que sei GRASP é ponto inicial ao Design Patterns...
http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)
|
|
|
|
Você pode criar uma classe para mapear essa tabela de relacionamento N para N (ItensPedidos) e mapear como relacionamentos Itens 1 para N -> ItensPedidos -> N para 1 Pedidos
Ou também pode utilizar a anotação @JoinTable.
Dê uma estudada aqui: http://www.hibernate.org/hib_docs/annotations/reference/en/html_single/
Esse link é do Hibernate Annotations, cuidado que algumas anotações realmente só funcionam para o Hibernate, se um dia for usar JPA puro (EntityManager), algumas anotações podem não funcionar.
Informei esse link porque apesar de haver essas exceções gosto muito nas documentações do Hibernate.
|
|
|
|
Acho que tem um problema de conceitos aí. Não existem "obejtos do tipo bean", JavaBeans são componentes editáveis por ferramentas gráficas, com o empo o nome passou a designar a convenção de usar métodos set/get mas ser um "Bean" não tem relacionamento com o tipo d eproblema que discutimos aqui. POJOs também são não relacionados, um POJO pode ser um JavaBean, um JavaBean pode ser ou POJO, ou não. São conceitos bem diferentes: http://blog.fragmental.com.br/2006/05/16/strict-pojos/
Acho que entendi...
Agora vms debater mais sobre a idéia de regras de negócio...
Onde você normalmente coloca as regras de negócio? Suas Entitys contém as regras de negócio? Ou algum outro objeto as contém? Como um VO?
Acho "estranho" colocar essas nas Entitys.
|
|
|
|
Não confunda entidades relacionais com objetos, eles são bem diferentes.Entidades relacionais normalmente são apenas uma representação de comod ados são persistidos.
Tem razão talvez tenha misturado um pouco as coisas, mais como estavámos falando de DAOs, achei que os objetos em questão eram as entidades.
E como você utilizaria dados sem lógica? Repetindo a lógica em outros sistemas?
Hehehe... Essa discussão vai longe, prefiro utilizar objetos do tipo Bean, do que POJO, costumo ter uma classe "controladora" (com regras de negócio) para a entidade em questão.
Não sei respondi a sua pergunta mais a lógica de dados fica em outra classe, se forem as mesmas regras utilizo a mesma classe controladora.
Acho que isso é mais uma questão de preferência mesmo...
|
|
|
|
Lembra a história de que um Objeto possui estado e comportamento. Pois é, o estado são os atributos da classe e o comportamento os métodos com a implementação da regras de negócio.
Apesar de concordar com essa sua opinião, não acho que isso deve valer para entidades (objetos que representam um registro no banco de dados).
Quando se coloca regras de negócio em uma entidade, raramente é possível aproveitar a mesma entidade em um outro sistema, porque colocando as regras de negócio na entidade amarramos totalmente o sistema a entidade.
Sei que esse tipo de coisa gera muita polêmica... 
Outra duvida que sempre tive em relação ao DAO é se é aconselhavel criar vários métodos mas todos com idéia de persistencia ou se o ideal é criar apenas um método salvar e ele se vira para ver o que já está no banco referente ao objeto e o que não está e fazer as atualizações necessárias.
O DAO não deve conter regras de negócio, somente operações de CRUD, portanto na minha opnião o ideal é criar apenas um método salvar e ele ser virar para fazer um insert ou um update. Mais nunca no mesmo DAO, métodos do tipo: salvar(x), salvarSeAtivo(x).
Repare que no segundo método existem regras de negócio, ou seja, o método só salva a entidade em questão se estiver ativa. Esse tipo de regra deve ficar preferenciamente em uma camada de negócio. Facilitando assim o reaproveitamente deste DAO em outro contexto, ou mesmo outra aplicação.
|
|
|
|
Tem o serviço com a JVM dedicada: http://site.locaweb.com.br/assinaturas/jvm_dedicado.asp
Agora o serviço sem a JVM decidada eu não achei também... Não sei se extinguiram essa opção...
|
|
|
|
Quantos elementos tem a sua lista?
O que acontece é o seguinte, quando você remove o elemento 0 (na primeiro iteração)
O elemento 1, vai para a posição 0, já na segunda interação ele vai tentar remover um elemento q talvez não exista.
Se a sua lista tiver mais de 1 elemento em algum momento o seu código pode pedir para remover um indice que não existe mais..
Será q consegui me explicar?
|
|
|
|
Muitas pessoas dizem que dependendo do caso não vale a pena criar uma camada de negócio, eu discordo totalmente disso.
Acredito que sempre vale a pena criar uma camada de negócio antes dos DAOs, afinal mesmo que sua regra de negócio seja muito simples, você não sabe o quanto o seu sistema pode crescer ou ser modificado, seja por pedidos do cliente ou pela própria evolução do sistema.
Respodendo a sua pergunta. Sim na minha opinião fica errado chamar os DAOs diretamente de uma Servlet ou página JSP.
|
|
|
|
Então como você mesmo disse são paramêtro de inicialização da JVM, então depende de como o plug-in para o Eclipse foi construido, se um ou mais plug-in utilizarem a memória de geração permanente a resposta e sim..
Então depende dos plug-ins.
Quando o espaço de geração permantente acaba, a JVM lança uma exceção, não se preocupe muito com este valor (no eclipse), 128mb é o suficiente para que o Eclipse funcione corretamente.
|
|
|
|
|
MaxPermSize é o espaço máximo que a JVM vai alocar para objetos de geração permanente (que nunca serão desalocados). Ex: Atributos estáticos.
|
|
|
|