Aplicações Java sem frameworks de persistencia padrão

Procure mais sobre JPA, que é o padrão inclusive seguido pelo Hibernate atual.

Na prática ficaria dificil. Vc pode utilizar somente bibliotecas do JPA, mas provavelmente um hora ou outra, num cenário mais complexo vai precisar recorrer às facilidades do toplink, hibernate e afins.

Agora falando do ponto de vista arquitetural, não vejo razões para se criar um projeto que seja multi-biblioteca.

Giulliano:

Agora falando do ponto de vista arquitetural, não vejo razões para se criar um projeto que seja multi-biblioteca.

Fugindo do escopo da pergunta do nosso amigo, mas essa razão é a a mesma que eu aponto para quando dizem que vão criar DAO mesmo com o advento do JPA. Nunca vi um projeto que precisou desistir de mecanismos ORM para ser reescrito em JDBC puro, por exemplo. O máximo que acontece é trocar algum ponto de desempenho sensível por uma consulta nativa via JPA.

Claro…o uso polimórfico do DAO…vc ja não esta usando??

Com certeza JPA é a especificação padrão para esses frameworks de persistencia, assim como JSF é padrão de especificação para criação de bibliotecas de componentes visuais.

Com certeza não se pode ficar atrelado a um framework destes. O foco é manter-se focado na especificação, mas não no framework em si. Vai que tal framework seja descontinuado ou ocorra outro problema qualquer, sei lá.

Entendo o que os colegas estão dizendo que tais frameworks trazem facilidades e concordo com isso, até pq uso o Hibernate e gosto muito mas, ainda tenho um pé atras com isso.

Mas valeu, mas ainda vou tentar montar uma forma, que utilize as facilidades de tais frameworks, mas seja genérico, ou seja, em poucas palavras de programador sonhador, quero ter a liberdade de escolher o framework de persistencia, via uma classe genérica.

Valeu

Jean

Ainda to boiando…
Uns dos benefícios do DAO é fazer uma camada de abstração para esconder a tecnologia de persistência utilizada…ele não disse que ta usando DAO???

Com certeza JPA é a especificação padrão para esses frameworks de persistencia, assim como JSF é padrão de especificação para criação de bibliotecas de componentes visuais.

Com certeza não se pode ficar atrelado a um framework destes. O foco é manter-se focado na especificação, mas não no framework em si. Vai que tal framework seja descontinuado ou ocorra outro problema qualquer, sei lá.

Entendo o que os colegas estão dizendo que tais frameworks trazem facilidades e concordo com isso, até pq uso o Hibernate e gosto muito mas, ainda tenho um pé atras com isso.

Mas valeu, mas ainda vou tentar montar uma forma, que utilize as facilidades de tais frameworks, mas seja genérico, ou seja, em poucas palavras de programador sonhador, quero ter a liberdade de escolher o framework de persistencia, via uma classe genérica.

Valeu

Jean

Com certeza JPA é a especificação padrão para esses frameworks de persistencia, assim como JSF é padrão de especificação para criação de bibliotecas de componentes visuais.

Com certeza não se pode ficar atrelado a um framework destes. O foco é manter-se focado na especificação, mas não no framework em si. Vai que tal framework seja descontinuado ou ocorra outro problema qualquer, sei lá.

Entendo o que os colegas estão dizendo que tais frameworks trazem facilidades e concordo com isso, até pq uso o Hibernate e gosto muito mas, ainda tenho um pé atras com isso.

Mas valeu, mas ainda vou tentar montar uma forma, que utilize as facilidades de tais frameworks, mas seja genérico, ou seja, em poucas palavras de programador sonhador, quero ter a liberdade de escolher o framework de persistencia, via uma classe genérica.

Valeu

Jean

Jean,

Sinceramente não sei se vale a pena você buscar esse tipo de independência

Se o seu sistema for simples é complexidade desnecessária para talvez nunca precisar ser usada, se o seu sistema for complexo acaba sendo um trabalho muito grande para conseguir esta “generalidade”.

Para sistemas muito grandes o que acaba acontecendo é você pensar em uma outra forma de integração usando um protocolo qualquer, webservices, SOA, etc

Na minha opinião não vale a pena o custo disto (tempo e esforço)

Abs

FernandoFranzini:

Ainda to boiando…
Uns dos benefícios do DAO é fazer uma camada de abstração para esconder a tecnologia de persistência utilizada…ele não disse que ta usando DAO???

Eu tenho um DAO genérico, que recebe o nome da classe de ed e partir dele cria a regra de persistencia.
Polimorfismo de DAO eu estou fazendo, mas o que quero é mais baixo nivel, ou seja, o sistema ser inteligente o suficiente para decidir por si qual framework de persistencia utilizar

Entendeu?

jean-vargas:

FernandoFranzini:

Ainda to boiando…
Uns dos benefícios do DAO é fazer uma camada de abstração para esconder a tecnologia de persistência utilizada…ele não disse que ta usando DAO???

Eu tenho um DAO genérico, que recebe o nome da classe de ed e partir dele cria a regra de persistencia.
Polimorfismo de DAO eu estou fazendo, mas o que quero é mais baixo nivel, ou seja, o sistema ser inteligente o suficiente para decidir por si qual framework de persistencia utilizar

Entendeu?

rael_gc:

Giulliano:

Agora falando do ponto de vista arquitetural, não vejo razões para se criar um projeto que seja multi-biblioteca.

Muito bem lembrado.

Fugindo do escopo da pergunta do nosso amigo, mas essa razão é a a mesma que eu aponto para quando dizem que vão criar DAO mesmo com o advento do JPA. Nunca vi um projeto que precisou desistir de mecanismos ORM para ser reescrito em JDBC puro, por exemplo. O máximo que acontece é trocar algum ponto de desempenho sensível por uma consulta nativa via JPA.

Temos aqui uma questão de que as pessoas possuem uma visão muito crua do “pattern”. Em uma aplicação que eu criei recentemente, utilizei o padrão DAO pois precisava buscar informações tando de uma base de dados quando de um arquivo xml. Centralizando este controle de dados.

Teve uma discussão de 100 páginas sobre isso, onde esse assunto foi esmiucado a exaustão. Recomendo a leitura e se tiver alguma consideracao, coloca lá no tópico: http://www.guj.com.br/java/252013-voce-nao-gosta-do-hibernate-eu-tb-nao-leia-para-entender-o-porque

Para mim ta muito claro…
Patter DAO - encapsular detalhes do mecanismo de persitencia adotado
Patter Abstract Method - encapsula de forma parametrizável o tipo polimórfico da família de objetos a ser criados. A solução em runtime consegue decidir que tipo de familia DAO vai usar…
Problema resolvido desde ano de 2000 e pouco…

FernandoFranzini:

Para mim ta muito claro…
Patter DAO - encapsular detalhes do mecanismo de persitencia adotado
Patter Abstract Method - encapsula de forma parametrizável o tipo polimórfico da família de objetos a ser criados. A solução em runtime consegue decidir que tipo de familia DAO vai usar…
Problema resolvido desde ano de 2000 e pouco…

Buenas

Eu vou dar uma olhada no link que vc me mandou, mas o caminho é por ali, mas vou estudar bem pra ver se é o que procuro.

Obrigado

JEan