Framework de persistência de objetos

Nao tenho tanta experiencia assim no assunto, mas me parece que fazer uma duplinha Hibernate/AOP seria uma ideia interessante.
Assim, a grosso modo, seria pegar os POJO’s do Hibernate que voce for utilizar e atraves de regras de AOP implementar os mecanismos de observador. Assim a grosso modo nao parece muito dificil.
Sera que algum mestre de AOP aqui do forum poderia validar/criticar minha sugestao?

Hmmmm… Isso está soando um pouco como JDBC RowSet. Mas, ainda assim a idéia é boa. Só não imagino porque você não pegou o codebase de um projeto já existente, como o Hibernate, e estendeu-o para atender às suas vontade.

Sobre a implementação de um observer, o Samuel Mota escreveu um artigo há pouco tempo atrás sobre como implementar este pattern usando OOP, sem interceptors: http://guj.com.br/user.article.get.chain?page=1&article.id=47 .
Mas, caso queira usar AOP e se divertir um pouco com interceptors, dê uma olhadinha no DynAOP: http://dynaop.dev.java.net

Salve Daniel,

o negócio é o seguinte, cheguei a dar uma estudada em Hibernate e Prevayler e o que realmente pesou neles parea mim foi o fato de criarmos arquivos .xml e cia para fazer o mapeamento das classes isso qdo não precisamos criar as classes DAO acredito que isto seja um pouco trabalhoso tomando como base uma simples tela de cadastro com uma meia dúzia de campos que eu ví em um exemplo na net. Mas de forma alguma estou questionando o engine do Hibernate e sim apenas propondo um mecanismo similar com alguns diferenciais e principalmente, que venha a tornar nosso trabalho mais produtivo. Qto pensei neste post sabia de todas estas constantes deveriam ser levadas em consideração e estou aberto a discussão, propostas e principalmente parcerias para criarmos um produto open-source, BRASILEIRISSIMO de muita qualidade.
O modelo que anexei é somente um ponto inicial para nossa atividade meu objetivo é construir inicialmente um modelo consistente, abrangente e principalmente simples de usar no dia-a-dia e mais uma vez convoco todos do fórum a participar

Os xmls do hibernate são indispensaveis dado que ele, nem qualquer outro, consegue adivinhar qual o mapeamento entre propriedades e colunas.

Cara, OUTRO framework de persistencia? :? Depois dos frameworks web, essa deve ter sido a roda mais reinventada da história…

Faltou convencer a todo mundo aqui que o Hibernate ou Prevayler nao sao solucoes possiveis ou satisfatorias para o que voce tem em maos. É perfeitamente possivel usar Hibernate ou Prevayler com observers, talvez não do jeito que vc tenha imaginado ou tentado, mas não acho que isso justifique o trabalho DESCOMUNAL que é criar um Hibernate da vida.

Me desculpe por estragar a festa, mas cedo ou tarde vc ia ouvir isso, entao vamos discutir essa parte logo

Sim, concordo porém penso em resolver isso na própria classe de negócio porque mesmo quando há alterações na estrutura do banco de dados não adianta somente reconfigurar o .xml e nossa aplicação sair rodando certo??? em alguns casos será necessária a recompilação das classes envolvidas então porque não deixar o mapeamento por conta destes objetos

Se for em alguns casos já é vantagem ter o xml já que estando dentro das classes será em todos os casos.

Arquivos de configuração não são tão ruins depois que você se acostuma com eles, é bem mais facil automatizar a criação e desenvolver ferramentas que os utilizem do que usando configurações hard-coded.
(veja os trocentos projetos pra criar mapeamentos pro hibernate de tudo quanto eh lado, a partir de classes, a partir do banco, na mao, etc.)

Acho que você ainda não captou todo o processo de mapeamento objeto-relacional e tudo que está relacionado a ele.
Se você simplificar demais correrá o risco de ter sua solução amarrada a apenas um cenário e não terá um framework, se for essa idéia vá em frente.
Se a idéia for mesmo ter um framework então pense em extender um, seus esforços terão muito mais resultado.
Pegue o hibernate e adicione os recursos que você quer … você se prenderá a fazer muito bem feito o que você quer e terá um framework de persistência muito bem testado e aprovado

:shock:
Como assim “resolver isso na própria classe de negócio”? Você está simplesmente jogando pela janela a abstração da camada de dados fazendo isso.
Além do mais, como o Samuel disse, arquivos de configuração são seus amigos e não seus inimigos. Eles dão as dicas para o framework relacionar propriedades e colunas de maneira de maneira mais flexível do que se as relações estivessem hardcoded. Concordo no ponto de que ficar gerenciando uma porrada de XMLs não é uma das tarefas mais agradáveis do mundo (acho que beanshell seria mais conveniente), mas ainda assim melhor do que instruir o framework a relacionar propriedades e colunas diretamente no código.
Outro ponto interessante que o Carlos comentou (e que eu já havia comentado) foi a “reinvenção da roda”. Não sou contra isso, principalmente quando as opções disponíveis não satisfazem a sua necessidade. Mas, convenhamos, as características que você pretende embutir no seu framework podem ser muito bem implementadas sobre um outro framework de persistência já existente, como o Hibernate, cuja licença (LGPL) permite a sua extensão e redistribuição.

Gostaria de deixar bem definido algumas coisas:

O caso usar ou não um arquivo .xml ou similar é uma opção válida (concordo) mas vamos analisar na prática: Em que situação vc simplesmente modificaria um .xml sem ter que recompilar sua classe? a não ser que o DBA errou o nome do atributo na base de dados caso contrário certamente vc precisará criar ou modificar o atributo de sua classe… ainda trabalho fortemente ligado a bancos de dados relacionais onde o banco é definido muito antes de qualquer a aplicação e está tem que ser moldada para rodar nele inversamente ao uso do Prevayler que utiliza mecanismos de serialização em disco…
Não quero de forma alguma questionar o uso de tais fw´s como certo ou errado somente acho que no dia-a-dia a música que toca é diferente, principalmente em projetos com um cronograma espremido e quanto mais artificios pudermos criar para obter produtividade (reuso) certamente será bem vindo e esse é o escopo do meu projeto. Confesso que fiz algumas experiências com ambos e particularmente são excelentes no que se propoem a fazer (persistir objetos) e só isso, eu quero uma total integração com a camada de apresentação o que seria um ++ neste fw. Concondo qdo dito que se eu me apegar a apenas um cenário não será um fw e sim uma coleção de classes para atender o meu objetivo porém reforço que a intenção não é parar nisso.
Agora um ponto importante a ressaltar, alguém do fórum topa extender o Hibernate por exemplo a um fw que tb incorpore a camada de apresentação? tem idéias de como fazê-lo? idéias de como automatizar as exigências (burocracias) do Hibernate? estou totalmente aberto a discussão e novas propostas, esse foi o motivo de provocar este post.
O impacto está sendo gerado porque estou pensando em formas de diminuir o esforço (braçal) meu e de minha equipe de trabalho, dexando-nos somente preocupados com implementação de regras de negócio e não simplesmente utilizar um fw conceituado, testado, enfim mas que para nós infelizmente só resolve parte dos problemas…

[]´s

:shock:
Como assim “resolver isso na própria classe de negócio”? Você está simplesmente jogando pela janela a abstração da camada de dados fazendo isso.

Ignorem isso (preciptação). Dá sim para implementar a persistência diretamente nas classes de negócio, conseguindo isolar os mecanismos de acesso a dados.

Então, não há justificativa para você montar um outro framework de persistência. Convém você montar componentes que se integrem fortemente com algum framework.

Esse seu post ai de cima tem alguns pontos importantes:

1. “mais artificios pudermos criar para obter produtividade (reuso)” :arrow: lembre-se que a lei do mínimo esforço engloba também não reinventar a roda, cada um faz o que lhe compete, no caso deixe que um framework de persistencia persista e seu projeto faça a integração da persistencia com a camada de apresentação. Com sorte seu projeto será tão bem projetado que vai ser independente da camada de persistência :shock:

2. “alguém do fórum topa extender o Hibernate por exemplo a um fw que tb incorpore a camada de apresentação?” :arrow: Nop. Mal to terminando meu TG :? quem me dera me meter com o Hibernate
   Mas uma observação é válida … ao começar a trabalhar com um projeto open-source não tente entende-lo por completo (ainda mais um que já tá grandinho como o Hibernate), tente apenas entender os porques e comos necessários pra determinada tarefa, tarefa por tarefa … no fim você terá entendido boa parte do código do projeto sem ter se desesperado, entrado em depressão ou qualquer coisa relacionada ao susto de vc não entender bulhufas do código logo de cara

3. “pensando em formas de diminuir o esforço (braçal) meu e de minha equipe de trabalho” :arrow: mais uma vez, acredite, você não vai querer ter que começar do zero um framework de persistência com todas as funcionalidades e abstrações como o Hibernate tem soh pra adicionar uma caracterísitca que nem é função do framework ter. Una as força e ai sim você diminuirá o esforço, comece do zero e você muito provavelmente nunca terá um framework pronto para produção

(NOTA: nós todos aqui podemos estar errados te desencorajando a começar esse projeto, podemos ser um bando de preguicosos (serve pro Daniel e pro CV) incompetentes e se você nos ignorar terá um framework brazuca com ótima qualidade, na verdade faço votos que essa nota seja verdadeira … mas é que é muito comum vermos projetos começando grandes demais e nunca terminados, dá uma dó danada, prefiro(imos) ver um projeto bem focado sair com glória )

De qualquer jeito … keep walking :lol:

“smota”:

(NOTA: nós todos aqui podemos estar errados te desencorajando a começar esse projeto, podemos ser um bando de preguicosos (serve pro Daniel e pro CV) incompetentes e se você nos ignorar terá um framework brazuca com ótima qualidade, na verdade faço votos que essa nota seja verdadeira … mas é que é muito comum vermos projetos começando grandes demais e nunca terminados, dá uma dó danada, prefiro(imos) ver um projeto bem focado sair com glória )

De qualquer jeito … keep walking :lol:

Eu admito: sou muito preguiçoso mesmo. Mas não quero desencorajar ninguém. Se você estiver mesmo determinado a fazer um framework de persistência que englobe camada de visão, go ahead!! Se precisar de algumas ajudas, tirar dúvidas a respeito de implementações, conte conosco. Mas, como o Carlos, o Samuel e eu frisamos, dá um trabalho descomunal construir um framework a partir do 0.
Além do mais, se você for um cara mais purista e for buscar lá a definição de um framework, você verá que eles servem como solução para um domínio específico.

Ainda bato na tecla de que seria mais conveniente você criar um conjunto de componentes que trabalhem muito bem integrados a um framework de persistência qualquer.

Concordo em todos os pontos com o smota. Uma coisa que eu queria soh botar mais enfase em cima: se vc quer bolar um framework generico pra poupar esforcos, voce nao esta nem bolando um framework generico, nem poupando esforcos.

Se um framework nasce naturalmente do seu sistema sem vc perceber, e aih voce comeca a torna-lo um pouco mais generico (como foi o caso do Hibernate), otimo. O problema eh quando vc resolve parar tudo e inventar a salvacao da lavoura logo de cara. Eh a chave pra cair de boca em problemas MUITO maiores que vc nem se lembrava, ou nem sonhava existir, e que o framework anterior resolvia muito bem

Amigos,

sinceramente estou muito grato a todos pelo incentivo :lol: porém acho que não soube me expressar no ínicio deste post, o negócio é que nós aqui da empresa estamos iniciando uma aplicação swing e inevitávelmente precisamos persistir as informações de alguma forma e eu acabei criando “digamos” uma coleção de classes para executar estas tarefas e a sua essência está funcionando entendem??? Reforço, pensei em usar o Hibernate (pessoal não tenho nada contra, pelo amor de Deus) e também não estou projetando um igual ou melhor apenas tentando validar com srs a nossa necessidade que hoje é produzir classes e formulários com a maior eficiência possível (infelizmente temos um cronograma a ser seguido e não dá pra guardá-lo embaixo da mesa) as coisas tem que acontecer… o único ponto (reinventar a roda) talvez foi um pouco mal colocado da minha parte… Na prática queremos uma coleção de classes que resolvam o problema de ficarmos implementando linhas e linhas e linhas de código que servem apenas como apoio na aplicação (trazer os dados de um objeto em um formulário por exemplo) que não pode ser nosso foco, temos que pensar na em que regras de negócio implementar em tais classes agora como elas vão aparecer na tela realmente os desenvolvedores não estão interessados. Acho que poderia até usar o hibernate se ele não exigisse aquela parafernália de classes de apoio, fosse algo mais simples de trabalhar do dia-a-dia, enfim, por questões inteiramente ligadas a escrever muito para produzir pouco resultado e outro fator que talvez não estão levando em consideração é que inicialmente não estou prevendo um mundo inteiro de possibilidades como o hibernate, correto, estou me apegando apenas as nossas necessidades primordiais e deixando esta discussão para uma próxima fase do projeto onde aí sim gostaria que partilhá-lo em um source-forge da vida.
Desculpem se meu post está se estendendo tanto, mas na verdade era esse o objetivo. Agora não levando em consideração o fator (reinventar a roda) estou pensando errado quanto a implementação ou não??? Gostaria que além de tecerem comentários/críticas sobre o que é certo e errado, me ajudassem com padrões práticos de implementação, isso é possível???
Bom galera é isso, e volto a agradecer a atenção da comunidade!

Que “parafernália de classes de apoio”?

Acho que você não deveria se ater somente ao hibernate, antes de iniciar um projeto, na minha humilde opinião, você deveria conhecer
outros frameworks, que podem lhe auxiliar no desenvolvimento, você já
conhece o Velocity?

:oops:

Não conheço o Velocity! você pode me falar um pouco sobre ele??

“lcmetzger”:

outros frameworks, que podem lhe auxiliar no desenvolvimento, você já
conhece o Velocity?

:shock:

:roll:

Você pode utilizá-lo para automatizar o desenvolvimento de muitas classes java, Entity, VO, etc…

Use para tarefas repetitivas, maiores informações:

http://jakarta.apache.org/velocity/index.html

Não sei como o Velocity poderia ajudá-lo a desenvolver com Swing, mas talvez você devesse dar uma olhada no Naked Objects: http://www.nakedobjects.org

Daniel,

passei o dia de hoje pesquisando sobre padrões de aplicação e lí alguns documentos sobre os patterns mais utilizados inclusive um do Samuel que mostra a utilização do Observable (show de bola), será que vc pode me indicar outros neste mesmo grau tipo:

DAO, Factory, etc…

de forma bem didática, é que começei a captar a necessidade da separação das classes de negócio com persistência etc… e agora quero embalar no assunto. Ahh qualquer outra documentação ou até mesmo exemplo (pedaços de código que vc usa no dia-a-dia) são de muita valida para mim ok

Fique ligado na coluna semanal de Patterns do GUJ (que estreiou esta semana com Template Methods).
Agora, como indicação, eu recomendo que você leia sobre:
:arrow: Command
:arrow: Method Factory
:arrow: Service Locator
:arrow: Decorator

Pretendo falar sobre eles nas próximas semanas. Mas, se você estiver muito ansioso e não consegue esperar, então procure no Google sobre eles. Recomendo também um site que implementa os GoF patterns em C#: http://www.dofactory.com/patterns/Patterns.aspx

E é isso.