Lançado o MentaBean - Persistencia simples via configuração programática

microfilo wrote:

O Hibernate eh um framework cuja qualidade eh comprovada. Ele eh completo, por isso tem uma ou outra complexidade, nada que um programador relativamente competente nao consiga dominar.

Nos casos supracitados, qual é a complexidade?

Esse é o meu ponto. o hibernate, para persistir beans, nao tem complexidade nenhuma.

saoj wrote:Vc acha um saca-rolha simplório ou simples?

Nao me venha com analogia furada. E leia o comentario do DQO de novo.

saoj wrote:Eu fiz alguns testes aqui e funcionou ok. Mas está em beta ainda...

E cade esses testes que voce fez? Eu fui la olhar o repositorio, e ta aqui a versao mais recente do build.xml do Mentawai:

https://svn.sourceforge.net/svnroot/mentaframework/mentawai/build.xml

E nao tem uma mencao sequer as palavras 'test', 'unit' ou ate mesmo 'run'. Como voce espera que eu confie no seu codigo? Lendo a porra toda?

urubatan wrote:PS.: nada contra opções, mas qual a vantagem de fazer a mesma coisa que ja existe, só que mais dificil, menos flexivel e menos poderoso?

Poder dizer "Fui eu quem fiz, ó!".

Isso realmene ultrapassou todos os níveis do absurdo. Mas bola pra frente, assim é a comunidade Java, cada um que faça o seu e o resto que se lasque.

JavaBaby Membro desde: 08/04/2005 17:20:52 Mensagens: 78 Offline

Paulo Silveira wrote:Oi Alberto

@org.hibernate.annotations.Entity(dynamicUpdate=true)

Desculpe fugir do tópico.
Deixar o update dinâmico (só atualizar as colunas modificas) não é uma boa pratica? porque então o default é false?

Entity.html#dynamicUpdate()

Penso que o Menta deve concentrar-se no MVC e delegar outras atividades que não são de sua competência direta para outros frameworks especialistas e já consagrados no mercado.

No máximo, o Menta poderia adotar um desses frameworks especialistas como padrão e fornecer certas facilidades para se trabalhar com ele. Por exemplo, caso o Menta quisesse facilitar a vida de alguns usuários que só querem trabalhar com objetos, sem se preocupar com JDBC, Mapeamentos OR, etc, poderia usar como padrão o DB4O (só como exemplo, pois como é GPL "contamina"). Tutorial pra quem tiver curiosidade: http://www.db4o.com/about/productinformation/resources/db4o-4.5-tutorial-java.pdf.

Persistência é uma coisa que deve ser levada a sério, pois os dados são a alma de qualquer sistema e frameworks como Hibernate, Ibatis, etc, já estão maduros o suficiente para assumirem tal tarefa.

[EDITADO]
Só para acrescentar, antes que me corrijam, o db4o também possui uma licença comercial.

[/EDITADO]

fmeyer wrote:

Codigo sem teste unitario eh codigo inutil.

ps. isso vai ser engracado ...

Vc é patético. Eu trabalho numa empresa que gira milhões de dólares por dia, coloca mais de 2 milhões de ordens no mercado por dia e realiza perto de 150 mil transações em bolsa por dia.

E lá não tem um teste se quer. Zero testes unitários.

O sistema e a empresa vão muito bem, pode ter certeza disso.

Inútil são esses seus comentários...

saoj wrote:Vc é patético.

Ate onde isso vai? "E voce eh bobo. E feio. E narigudo. Te encontro a 200m da escola, perto do ponto de onibus, e vc vai ver so!"

saoj wrote:E lá não tem um teste se quer. Zero testes unitários.

E isso eh pra se achar bonito? Bom, parabens, vc trabalha num puteiro onde ninguem leu nada sobre desenvolvimento de software de qualidade nos ultimos 20 anos. Ou leu, mas nao aplicou e preferiu ser cauboi, pq da pra se manter no emprego mais tempo. Eu nao tenho muito o que ver com isso, a nao ser ficar um tanto chateado em ver que a nossa profissao nao consegue evoluir desse jeito.

saoj wrote:Inútil são esses seus comentários...

Nos poupe, vai?

=== Respondendo ao primeiro post do Paulo:

getter e setter não é para o framework que usa reflection e pode acessar diretaente o campo privado. getter e setter é para vc poder manipular o bean, como vc está fazendo no seu exemplo.

- nao precisa do codigo de init do contexto
- nao precisa do load beans

Realmente faltou um CoC para o MentaBean. Se o campo é string por default o tipo deveria ser String, sem necessidade de configuração. (Vou fazer isso!)

- o hibernate tambem faz update so dos campos que esta dirty se voce quiser. tem muita gente que desconhece mesmo
- o hibernate pode fazer update sem fazer o load. voce pode usar o merge para isso, ou usar HQL com update.

Eu não sabia disso e até pouco tempo atrás acho que não era assim, ou seja, ele fazia um update em todos os campos. Mas tudo bem, isso é importante para qualquer framework suportar. Veja o que nosso amigo falou sobre isso:

alott wrote:
Paulo, aproveitando a onda, vc poderia explicar como configurar o hibernate para fazer este update inteligente nos objetos transientes? Procurei pelo site do hibernate e pelo google e não tive sucesso. Desculpem a fuga do tema do topico., mas esta é uma sabedoria que deve ser compartilhada.

- o hibernate suporta criacao de tipos novos, igualzinho como voce fez.

Isso é básico para qualquer framework.

- alem de auto increment e sequence, suporta propria tabela de sequence, hilo, genracao de id universal e possibilita voce inventar seu sistema de geracao de chaves

Suporta até redes neurais. Acho que se já suportar os principais mecanismos dos principais bancos já está bom. (Não estou levando em conta a independencia de banco de dados aqui, por achar desnecessária em 95% dos casos. Ou vc muda o seu banco de dados toda hora?)

- Para mudar o nome da coluna, no hibernate basta @Column(columnName="bla")

A idéia aqui é usar configuração programática, como o Mentawai.

- Da para fazer a configuracao TODA programaticamente, isso tem alguns anos.

Sim, já tinham me falado isso. O problema é que nínguem usa, não é documentado, ninguém dá exemplo e os próprios autores do Hibernate não encorajam, ou seja, XML e Annotations estão em todos os lugares quando o assunto é Hibernate. É como a configuraçõa programática para validação do Struts. Existe, mas é tão pouco falado/divulgado/usado/documentado que é como se não existisse.

cv wrote:

saoj wrote:Vc é patético.

Ate onde isso vai? "E voce eh bobo. E feio. E narigudo. Te encontro a 200m da escola, perto do ponto de onibus, e vc vai ver so!"

saoj wrote:E lá não tem um teste se quer. Zero testes unitários.

E isso eh pra se achar bonito? Bom, parabens, vc trabalha num puteiro onde ninguem leu nada sobre desenvolvimento de software de qualidade nos ultimos 20 anos. Ou leu, mas nao aplicou e preferiu ser cauboi, pq da pra se manter no emprego mais tempo. Eu nao tenho muito o que ver com isso, a nao ser ficar um tanto chateado em ver que a nossa profissao nao consegue evoluir desse jeito.

saoj wrote:Inútil são esses seus comentários...

Nos poupe, vai?

Puteiro é sua casa, Carlos Vilela. Manere no seu linguajar. Respeito é bom e todo mundo gosta, ok?

Fala para as diversas pessoas que utilizam o framework para elas não utilizarem mais porque o framework não tem testes unitários.

Fala para o meu chefe que apesar de ele faturar um bilhão de dólares por ano numa empresa com 50 funcionários, ele deveria jogar tudo fora e ir trabalhar com o CV e seus testes unitários.

Abaixa a sua bolinha amigo, porque eu tenho munição para rebater suas críticas mal-educadas.

Maurício Linhares wrote:

urubatan wrote:PS.: nada contra opções, mas qual a vantagem de fazer a mesma coisa que ja existe, só que mais dificil, menos flexivel e menos poderoso?

Poder dizer "Fui eu quem fiz, ó!".

Isso realmene ultrapassou todos os níveis do absurdo. Mas bola pra frente, assim é a comunidade Java, cada um que faça o seu e o resto que se lasque.

O que ultrapassou todos os níveis do absurdo é o incomodo que isso gera nas pessoas. Enquanto algumas elogiam, contribuem, incentivam, outras caem matando. Quando fiz o Mentawai foi a mesma coisa. Fui massacrado aqui no GUJ e tb no exterior. Ainda bem que não desisti, ou melhor, esses ataques só me deram mais força para seguir em frente com o projeto. E hoje fico feliz em ver que muitas pessoas utilizam em casos de sucesso aqui e no exterior. Recebo muitos pedidos para entrar no time de desenvolvedores, etc e tal. Será que estou cometendo um crime. Será que estou fazendo algo errado. Será que deveria jogar fora o framework e usar Struts ou WebWork? Para algumas pessoas sim né...

Hei, acorda! Foi apenas um teste. Eu estava procurando por comentários sóbrios, técnicos como o Paulo fez. Perfeito. Sem xingamentos. Um verdadeiro profissional.

Agora o que dizer de CV, fmeyer e vc agora com esse comentário?

Isso é que é triste. Pessoas que não fazem nada, condenam tudo e se acham o máximo! Eu gosto de dar a cara a tapa. Sabia que ia gerar esses tipos de comentários da "galerinha do mal do GUJ".

Se errei, como errei com o Lohis, com o Space4J, etc. me desculpem. Não precisa usar. Coloca um BLOCK no seu browser para nem entrar na página do Mentawai.

Agora não se iludam que eu vou parar de tentar, ok?

Além de tudo isso que o Paulo citou, Hibernate permite que você crie desde soluções de "CRUD simples para Beans" até "persistência entre objetos com relacionamentos *malucos*", ou seja, é mais flexível e não vai obrigar que eu reescreva todo meu sistema novamente porque, de repente, ele deixou de ser um simples "cadastrinho" e passou a ser um sistema um pouco mais complexo.

Concordo com vc. Há sempre o risco de um sistema simples se tornar complexo, mas se isso realmente acontecer será MUITO TRANQUILO migrar o seu sistema fixo para Hibernate e começar o seu sistema complexo.

Além disso, este projeto vai seguir a mesma política do MTW de não ter testes unitários para quase absolutamente nada? Como você pretende garantir backward compatibility conforme sua biblioteca evolui sem testes?

Testes só é necessário se o seu sistema estiver mal-feito. Boas práticas de OO (herança e override) te permitem que vc estenda o teu sistema sem quebrá-lo. Eu faço isso todo o dia no meu trabalho, trabalhando com sistemas críticos que controlam milhões de dólares. O que não pode é colocar um bacurau para alterar isso e colocar em produção. Tem que ter disciplina, organização e programar "ORIENTADO A CONTRATOS", ou seja, quando se introduz um novo contrato vc precisa ter 100% de certeza que o contrato antigo continua lá, bonitinho.

saoj wrote:Manere no seu linguajar. Respeito é bom e todo mundo gosta, ok?

Reciprocidade funciona mais ou menos assim: a gente trata as pessoas como as pessoas tratam a gente. Logo...

saoj wrote:Vc é patético.

saoj wrote:Puteiro é sua casa, Carlos Vilela.

Isso nao eh aceitavel. E voce comecou. E eh Villela, nao Vilela. Se vai chamar pelo nome completo como sinal de que vc esta rodando a baiana, alias, voce pode tentar Carlos Eduardo Villela de Andrade Neto, da proxima.

saoj wrote:Fala para as diversas pessoas que utilizam o framework para elas não utilizarem mais porque o framework não tem testes unitários.

A decisao eh delas, mas se elas nao tem o bom-senso de decidir nao usar um framework que ja esta na quase na versao 2 e nao tem um teste automatizado sequer, talvez elas tenham uma licao importante a aprender.

E, caso vc nao tenha notado, eu estou falando pra essas diversas pessoas (afinal, o forum eh publico).

saoj wrote:Fala para o meu chefe que apesar de ele faturar um bilhão de dólares por ano numa empresa com 50 funcionários

Fala pro seu chefe dar um toque pra ThoughtWorks, a gente provavelmente tem muito trabalho a fazer por ai.

saoj wrote:Testes só é necessário se o seu sistema estiver mal-feito.

Caralho. Eu vou colar isso na parede. saoj, manda uma foto sua pra mim?

Fala pro seu chefe dar um toque pra ThoughtWorks, a gente provavelmente tem muito trabalho a fazer por ai.

Só se for para comprar a ThoughtWorks e te colocar como relações públicas CV.

A empresa é líder no mercado americano e talvez no mercado global. Fatura mais que qualquer outra na área de high-volume trading, recruta profissionais no mundo inteiro, o sistema é super estável, mas porque não tem testes unitários é uma merda, inútil.

Ok. A eterna briga entre teóricos e práticos. Papo-furado e resultados! Escolham o seu lado!

cv wrote:

saoj wrote:Testes só é necessário se o seu sistema estiver mal-feito.

Caralho. Eu vou colar isso na parede. saoj, manda uma foto sua pra mim?

- Testes são demorados

- Testes são chatos de se fazer

- Testes geralmente não conseguem testar todos os cenários.

- Testes possuem falso-positivos, ou seja, não acusam problemas mas quando vc coloca em produção dá algum erro.

- Na grande maioria dos casos é IMPOSSÍVEL reproduzir o ambiente de produção num ambiente de testes. (Pergunte para as mais de 20 bolsas para as quais eu tive que escrever uma conexão esse ano...)

- Se vc está modificando um sistema pouco organizado, sem boas práticas de OO vc com certeza precisa de testes. (que provavelmente não vão funcionar também)

- O JForum não tem testes unitários (acabei de falar com o Rafael Steil). É inútil tb? Peço que troquem o fórum do GUJ urgentemente, pois isso é um atente as boas práticas de tecnologia.

- Falei para o Rubem que se ele quisesse fazer testes unitários para o Mentawai ele poderia fazer sem problemas. Ele falou que sim, ok. Isso é muito importante. Fez 2 testes e não fez mais nada. Vai dizer que estava sem tempo para fazer isso. Ok. As pessoas são livres para fazer o que quiser...

Notícias, artigos e o maior fórum brasileiro sobre Java