:: Discussão sobre arquitetura escolhida

0 respostas
marciobarroso

Pessoal,

Atualmente estou trabalhando em um projeto onde foi possivel escolher todas as técnologias utilizadas.

Escolhemos então Hibernate para Framework ORM, Spring Framework para gestão de contexto ( DI e IOC ) e jaxws para disponibilizar os serviços criados.

No meu mapeamento de tabelas, tenho um relacionamento complexo:

Exemplo:

@Entity
class Node {

     private String name;     

     @OneToMany
     private List<Node> childs;

     ...
}

Este relacionamento pode então ter:

<node>
     <name>nome1</name>
     <childs>
          <node>
               <name>node2</name>
               <childs>
                    <node>
                         <name>node1</name>
                         <childs>
                              <node>...</node>
                         </child>
                    </node>
               </childs>
          </node>
     </child>
</node>

Por causa do mapeamento do hibernate, na geração do xml para o webservice, acaba gerando um ciclo infinito.

Então, comecei a pensar na arquitetura.

Não seria interessante eu ter além das minhas classes “Entity” (que mapeiam as tabelas para o hibernate) as classes VO ou POJO???

Desta forma, teria uma implementação não necessariamente igual ao meu mapeamento do banco e conseguirei limitar qual o nivel que eu quero da arvore de nodes.

Inicialmente eu estava utilizando as mesmas classes que mapeiam as tabelas para transitar entre as camadas da aplicação, inclusive para o client que acessaria os webservices.

Devido a problemas como este acabei criando então um POJO para cada classe de mapeamento do hibernate e usando estes pojos para trafegar entre as camadas.

Acho que estou no caminho certo né??

Alguém sugere outra solução para contornar este problema? em uma aplicação web comum eu não usaria (mesmo sabendo que é uma boa prática) um POJO para cada entity, e para os problemas de carregamento de coleções, usaria open session in view.

Criado 23 de dezembro de 2010
Respostas 0
Participantes 1