20 anos depois e ainda não entendemos reusabilidade

Olá!

Quanto a “usabilidade” posso afirmar que para muitos usabilidade significa ctrl+c , ctrl+v ao invés de gerar um framework/lib em que o código pode ser reaproveitado, é claro que esse cenário é muito melhor do que a 20 anos atrás, mesmo tendo empresas que querem produzir software que nem pãozinho em padaria, mas os desenvolvedores no geral estão melhor “munidos” de conhecimento.

Quanto a complexidade dos frameworks eu discordo em partes, claro que mesmo depois do annotations ainda temos que fazer N configurações mas eu agradeço por fazê-las, pois se o Hibernate por exemplo fosse simplista, provavelmente não se encaixaria em boa parte das situações que o aplico. Se o framework X tem N configurações é justamente para abranger o maior número de casos e promover ainda mais a reusabilidade, apesar de tudo, entendo o ponto de vista dela pois sei o parto que era escrever um EJB 2.x.

Eu as vezes me sinto como ela. Alguns sistemas estão burocráticos demais.

Mas sinto as vezes que a questão de persistencia em OO ainda não é um assunto bem resolvido. O hibernate é um ótimo mapeamento, mas ainda não é de longe tão trivial de usar quanto era manipular dados na época da programação estruturada.

Por outro lado, hoje também modelamos problemas mais complexos que, por consequência, exigem mais estrutura para serem modelados.

óitmo post

Porém eu discordo disso:

O weka, processing, hibernate(framework que não deixa de ser um conjunto de bibliotecas) e Spring não são bandaids. São ótimas ferramentas e eu poderia citar mais uma duzia de boas soluções.

Existe bibliotecas ruins?

Deve existir até pq qualquer um pode fazer uma biblioteca ou framework.

já add o blog aos meus favoritos…

[]`s

Eu acho meio complicado, sabe? Pensando por um lado, os programadores iriam escrever seus próprios ArrayList, Hashes e Threads. Isso eu acho que, além de custoso, seria um tanto perigoso, porque quem melhor pra escrever as APIs do que os caras que entendem grande parte da arquitetura da JVM? Não digo aquele overview de arquitetura, mas aquela coisa detalhada mesmo.

Por outro lado, acho que sair procurando jars pela Internet, em vez de programar algo trivial (ou construir uma classe que seja meio que essas “Tools” que a gente ve por aí) pra resolver um problema não seja programação. É pegar umonte de Lego usado e pronto. Fica aquela coisa colorida, ridícula e que, se precisar dar uma manutenção detalhada, vai custar muito caro pro programador.

acho que a mulher e principiante… e que ela usa os frameworks como bandaids por que ela quer…
cada framework desses por exemplo… Spring,Hibernate,Struts etc… voce tem 2 opções.

1 - Você aprende eles porca-mente em 5 minutos… porca-mente que eu falo e do jeito que a maioria sabe o “Fazer rodar” o mínimo para poder trabalhar.
2 - Pegar um livro de 500 paginas e aprender direito a ferramenta isso deve demorar 1 mes se a pessoa for dedicada.

o que o ocorre e que 90% das pessoas tem preguiça e esse frameworks sao muito tramquilos de aprender se estudados direito o Struts e simplesmente uma implentação do padrão de projeto front controler etc… e se voce for reinventar a roda toda vez.

Eu conheço a autora do blog e o que ela tem, definitivamente, não é preguiça. Eu mesmo, com anos de estrada, já me bati com arquivinhos de configuração em diversos frameworks, como o próprio Hibernate ou o Spring. O Hibernate era ainda muito pior antes do Java 5, quando você tinha que recorrer a dezenas de xmls separados da sua implementação de classe concreta.

Um problema que já vi em muita empresa é o pessoal procurar frameworks e confiar em qualquer coisa. Resultado, o projeto desse framework depois de um tempo é abandonado e a empresa fica na mão. Eu mesmo tenho um pé atrás ao escolher frameworks e procuro as que existam há alguns anos no mercado, que tenham uma equipe já grande e consolidada por trás.

Acho que o pessoal não compreendeu o que ela disse, ou eu não compreendi

Ao que me parece, a questão é a burocracia das bibliotecas, agora vai me dize quem uma classe em JPA é bonita com todas aquelas @Annotations, ou vai me dizer que um XML tbm é bonito com todas aquelas TAGs.

Concordo plenamente, a pior parte de um sistema é desenvolver a parte chata, mas que é a base para quem usa, lógico que é muito mais atraente trabalhar focado em logica, do que desenvolvendo cadastros básicos, mas enfim, nem tudo são flores, e não importa a sua profissão.

Concordo que muita coisa deveria ser muito simples, e pratica, e principalmente focada em extensibilidade, eu sou fã do conceito de classes abertas do Ruby, acho que você poderia alterar uma classe a qualquer momento, EU quero que essa classe seja do meu jeito e que se dane o que os projetistas do java pensaram quando criaram a classe String.

Quando a essas malditas configurações, aaaaaaaaaaaaa não vejo a hora da Convenção ao inves de Configuração chegar ao java, sabe, existem padrões em todos os projetos, e por que eu tenho que configurar tudo isso a cada minuto? Por que não posso customizar esse framework para ser do meu jeito? Por que tanto XML? Por que tanta Annotation? Por que tantos Frameworks? Essa ultima é facil, por que o cara não conseguiu usar um framework que ja tinha, criou o seu e disponibilizou, e vamos a nova bola de neve ehhehehe.

Concordo em muitos pontos, porém, ainda acho que as bibliotecas são muito uteis em alguns casos, e a escolha deve ser bem feita

Em momento nenhum ela falou que uma biblioteca não é útil. Mas eu concordo com a visão dela de que alguns problemas recorrentes demais, como persistência, ainda exigem muitas voltas e burocracias.

Veja bem, nós precisamos persistir dados praticamente desde que a informática foi inventada. E ainda não temos uma solução muito limpa e elegante.

ViniGodoy:

Em momento nenhum ela falou que uma biblioteca não é útil. Mas eu concordo com a visão dela de que alguns problemas recorrentes demais, como persistência, ainda exigem muitas voltas e burocracias.

Veja bem, nós precisamos persistir dados praticamente desde que a informática foi inventada. E ainda não temos uma solução muito limpa e elegante.

Se houvesse uma padronização de como um sistema deve ser desenvolvido seria fácil desenvolver uma solução elegante, com poucas configurações e etc. Mas justamente pela maneira de desenvolver ser muito “livre”, o framework acaba tendo de ser muuito flexível para atender a boa parte dos casos( Entenda-se por N configurações ), se for seguir por essa linha de pensamento quem está errado somos nós.

Olá,

Ela fala em algo bem importante, a geração de código automático pelas IDEs e afins. E eu sempre pensei dessa forma, se uma ferramenta for ela a responsável por gerar zilhões de linhas de código para você que ela seja á ÚNICA responsável por esse código.

Foi por isso que em um projeto eu bati o pé com o meu atual chefe - que ná época (mais de 2 anos atrás) -, ele insistiu para usarmos a implementação de JSF chamada de Woodstock, eu fiz os meus argumentos alegando eu que a ferramenta não tinha uma comunidade muito sólida, existiam ferramentias com mais tempo no mercado e como conseqüência, mais códigos feitos, mais gente trabalhando e mais problemas resolvidos. O argumento dele era que a ferramenta era “prática” fazendo uso de recurso visual (tipo matisse) para produzir as telas. Então eu falei: “quem vai dar manutenção nesse código tosco que o Woodstock gera?”

Ela fala do ponto de complexidade das ferramentas e frameworks, também estou de acordo. Eu ficava pensando na época no Struts e então eu me perguntava, onde diabos está a facilidade nisso aqui, e na verdade ninguém sabia me explicar de fato as vantagens de usá-lo ao invés do formato: JSP + Servlets, e isso foi meio que empurrado guela abaixo.

Abomino com todas as forças as fábricas de softwares. Porém de quem é a culpa? Da fábrica que lhe trata como code monkey ou do programador que relaxe e deixa se levar por tal situação?

Com relação a burocracia das ferramentas, eu penso o seguinte, o Hibernate por exemplo ele elimina da mão do programador muita coisa.

Existe burocracia pq existe muita complexidade a ser tratada.

Porém só temos o O/RM pq alguém não estava contente com a solução que existia na época.

Bom se ela reclama de que existem problemas antigos ainda não resolvidos, critica os principais frameworks/tecnologias do mercado E afirma que adora a parte de “encontrar e implementar soluções” na programação… bom pelo menos para mim está muito claro o que ELA deveria fazer…

sinceramente eu sou totalmente contra o uso desenfreado de frameworks. Se não há realmente um excelente motivo para usá-lo, então não use.

O real problema não está no framework, está em quem os utiliza!

ViniGodoy:

Em momento nenhum ela falou que uma biblioteca não é útil. Mas eu concordo com a visão dela de que alguns problemas recorrentes demais, como persistência, ainda exigem muitas voltas e burocracias.

Veja bem, nós precisamos persistir dados praticamente desde que a informática foi inventada. E ainda não temos uma solução muito limpa e elegante.

Sou da opinião que ainda não temos problemas limpos e elegantes para solucionar.

MaiqueL:

Com relação a burocracia das ferramentas, eu penso o seguinte, o Hibernate por exemplo ele elimina da mão do programador muita coisa.

Existe burocracia pq existe muita complexidade a ser tratada.

Porém só temos o O/RM pq alguém não estava contente com a solução que existia na época.

O hibernate não elimina a complexidade, ele elimina a “repetição de rotinas”, e só isso, a complexidade continua existindo, mesmo sendo de outra forma. O seu ponto tá certo!

Grinvon:

MaiqueL:

Com relação a burocracia das ferramentas, eu penso o seguinte, o Hibernate por exemplo ele elimina da mão do programador muita coisa.

Existe burocracia pq existe muita complexidade a ser tratada.

Porém só temos o O/RM pq alguém não estava contente com a solução que existia na época.

O hibernate não elimina a complexidade, ele elimina a “repetição de rotinas”, e só isso, a complexidade continua existindo, mesmo sendo de outra forma. O seu ponto tá certo!

sem comentários…

Em certos momentos me sinto também como a autora do blog. Antigamente no Hibernate quando se fazia as configurações utilizando XML, era terrível. Eu procuro utilizar bibliotecas e frameworks que já estão há alguns anos no mercado e que não corre o risco de ser abandado, como por exemplo, o hibernate. E também não devemos confiar em qualquer coisa, como o Vinny disse. Uma coisa que ainda acho complicada são as várias configurações que devemos fazer em arquivos WEB.XML das aplicações web quando queremos utilizar algum framework. Não seria mais fácil apenas adicionar o jar no classpath? E funcionar sem aquele monte de configurações? Enfim, ainda temos bastante coisa para mudar.

eu detesto xml, mas é complicado você simplesmente adicionar um jar e a mágica acontecer.

Eu fico pensando. Por que alguns desenvolvedores de frameworks gostam de criar vários arquivos em xml para configurar a aplicação? Será que por achar bonito aquele monte de XML com aquelas tags? Em certos momentos uma configuração do XML é necessária, como por exemplo, o Persistence.XML do JPA, por ter a configurações de conexão e entre outras coisas. Tempos atrás quando tentei utilizar o Spring, nossa foi sofrivel com aquele monte de XML. Não sei como o Spring está hoje, mas espero que melhor sem aqueles XML. Muitos de nos devemos procurar entender melhor o conceito de reusabilidade, por as vezes me sinto me agofando em um monte de burocracia.

Em questão de reusabilidade também para driblar esses montes de frameworks que surgem por ai, sem saber o rumo deles. Eu procuro desenvolver soluções proprias, mesmo que gaste algum tempo, com isso evito de ter que cair nas armadilhas de alguns frameworks, que não sabe se ficam ou se vai.

Por isto que existe o Convention over Configuration. Se você seguir os padrões de um framework construído com isto em mente, não precisa configurar nada.

A mágica é seguir o que o framework faz, sem mudar um pingo. A partir do momento que tem que customizar é que você tem que ler o manual mais atentamente.

O problema, caros, não é a reusabilidade, é a incompetência geral de não saber fazer um software.

A vasta, esmagadora, maioria dos desenvolvedores não conhecem a teoria suficiente para construir um software simples, e dos que conhecem, a vasta maioria ignora. Ainda vivemos no Reinado da Gambiarra e esse é o problema maior.

Ninguem pensa em construir uma plataforma de aplicação. Este é o primeiro passo para poder construir uma aplicação. Mas ninguem o faz. As pessoas acham que amarrar um spring um struts um hibernate e um commons-upload já soluciona todos os problemas. Soluciona todos os problemas durante um tempo, mas não todo o tempo.

As pessoas falham em entender que software de qualidade é mais barato que software de má qualidade. Ao contrário de um prédio ou um carro um software é mutável por natureza e o custo do software está na sua manutenção e não na sua criação. Cortar os cantos durante a construção inicial apenas aumenta o custo de manutenção.

O GUJ está recheado de discussões sobre melhores formas de fazer software mas poucos as aplicam. as pessoas, principalmente os novatos, são muito imediatistas e só se preocupam em fazer o negocio funcionar. mas o objetivo não é fazer funcionar, isso qq macaco sabe fazer (code-monkey) o objetivo e manter funcionando a custo zero ( ou mais proximo de zero possivel). O objetivo é aumentar o lucro diminuindo o custo.

Se vc vende um software on demand por 100.000 e lhe custa construi-lo 10.000, mais 40.000 por ano para manter em menos de 3 anos ele está dando prejuizo, mas a vida util do software é de 8 a 10 anos. Mas se lhe custa 40.000 e mais 5.000 por ano, vc chega no final da vida util com margem de sobra.

São estas contas que as pessoas não fazem. E aqui , a culpa, é especialmente dos ditos “gerentes” que não têm noção alguma de construção de software - e não me refiro à parte tecnica. Mas os maiores culpados são os idiotas dos diretores destes gerentes que não entendem que estão perdendo dinheiro diáriamente - estão sendo quase literalmente esventrados e desanguinados. Depois as empresa de software falem e ninguem sabe porquê…

O problema, caros, não é a reusabilidade, é a incompetência geral de não saber fazer um software.

A vasta, esmagadora, maioria dos desenvolvedores não conhecem a teoria suficiente para construir um software simples, e dos que conhecem, a vasta maioria ignora. Ainda vivemos no Reinado da Gambiarra e esse é o problema maior.

Ninguem pensa em construir uma plataforma de aplicação. Este é o primeiro passo para poder construir uma aplicação. Mas ninguem o faz. As pessoas acham que amarrar um spring um struts um hibernate e um commons-upload já soluciona todos os problemas. Soluciona todos os problemas durante um tempo, mas não todo o tempo.

As pessoas falham em entender que software de qualidade é mais barato que software de má qualidade. Ao contrário de um prédio ou um carro um software é mutável por natureza e o custo do software está na sua manutenção e não na sua criação. Cortar os cantos durante a construção inicial apenas aumenta o custo de manutenção.

O GUJ está recheado de discussões sobre melhores formas de fazer software mas poucos as aplicam. as pessoas, principalmente os novatos, são muito imediatistas e só se preocupam em fazer o negocio funcionar. mas o objetivo não é fazer funcionar, isso qq macaco sabe fazer (code-monkey) o objetivo e manter funcionando a custo zero ( ou mais proximo de zero possivel). O objetivo é aumentar o lucro diminuindo o custo.

Se vc vende um software on demand por 100.000 e lhe custa construi-lo 10.000, mais 40.000 por ano para manter em menos de 3 anos ele está dando prejuizo, mas a vida util do software é de 8 a 10 anos. Mas se lhe custa 40.000 e mais 5.000 por ano, vc chega no final da vida util com margem de sobra.

São estas contas que as pessoas não fazem. E aqui , a culpa, é especialmente dos ditos “gerentes” que não têm noção alguma de construção de software - e não me refiro à parte tecnica. Mas os maiores culpados são os idiotas dos diretores destes gerentes que não entendem que estão perdendo dinheiro diáriamente - estão sendo quase literalmente esventrados e desanguinados. Depois as empresa de software falem e ninguem sabe porquê…

Concordo plenamente com o sergio muitos desenvolvedores por não ter experiência ou não procurar entender a teoria de construção de software acabam por fazer gambiarras no sistemas. Devemos ter conhecimento daquilo que iremos desenvolver, se você vai construir um sistema financeiro, devemos entender como funciona a parte financeira. O que vejo por ai e que algumas empresas não passam esse conhecimento para os desenvolvedores ou o proprio não procura entender. E com isso o custo do sistema acaba aumento, fica dificil a manutenção e o sistema correndo risco de afundar

De todas as threads que ja vi nesse forum acho que essa foi uma das mais ingênuas. O texto é precário e recheado de trivialidades. Na edição de 15 Anos de Design Patterns há um artigo mais sério e crítico de Glauco dos Santos Reis na coluna Provocação Digital sobre o que é programar Orientado a Objetos hoje em dia e onde Design Patterns e reusabilidade se enquadram nesse contexto.

:shock:

Lí o post e achei bacana porem na minha opinião o conteúdo todo é uma grande retórica.

Coisas que me passaram pela cabeça durante a leitura:

1. Desenvolvimento de software AINDA NÃO É PARA QUALQUER UM. Apenas a Microsoft disse isso e ainda por cima ficou riquissima (ponto pra ela) tentando convencer a maioria disto.

2. É melhor ler pouco e entender bastante do que ler muito e entender quase nada.

3. Se desenvolver sistemas fosse simples, muito simples quase ridiculo ao ponto de não precisar de ler um tutorial EM PORTUGUÊS o mercado de computação não pagaria o que paga.

4. Softwares ruins tem origem nas mãos de quem acha que a facilidade tem que estar do lado de quem FAZ e não de quem USA, isto é um fato.

5. O uso de frameworks / libs é uma questão de escolha, não é obrigatório; você decide qual utilizar e SE VAI UTILIZAR; se o resultado não foi tão bom como esperava o erro tambem está em você. Boa parte dos frameworks disponibiliza o código fonte, precisa dizer algo mais?

6. Negligenciar nas decisões, nas escolhas nos estudos e posar de vítima é fraco tente evitar chegar a este ponto.

7. Se meter em computação APENAS por dinheiro dá nisso.

…

flws

Ler a opinião da churrasqueiro foi muito legal brincadeira …

Gostei do post do Sérgio …

Uma coisa é fato discordo de muitas coisas no texto da menina mas pelo menos ela escreve bem.

E nessas horas um post do Guilherme Silveira ou Paulo ou Luca cairia muito bem…

[]`s

Classico usuário opensource que usufrui de código gratuito a vida toda e agora reclama quando descobre que o ecossistema em torno da sua tecnologia de estimação (Java) não escala para as novas demandas do cotiadiano, ou seja, torna sua vida um inferno e não o contrário.

fantomas:

:shock:

Lí o post e achei bacana porem na minha opinião o conteúdo todo é uma grande retórica.

Coisas que me passaram pela cabeça durante a leitura:

1. Desenvolvimento de software AINDA NÃO É PARA QUALQUER UM. Apenas a Microsoft disse isso e ainda por cima ficou riquissima (ponto pra ela) tentando convencer a maioria disto.

2. É melhor ler pouco e entender bastante do que ler muito e entender quase nada.

3. Se desenvolver sistemas fosse simples, muito simples quase ridiculo ao ponto de não precisar de ler um tutorial EM PORTUGUÊS o mercado de computação não pagaria o que paga.

4. Softwares ruins tem origem nas mãos de quem acha que a facilidade tem que estar do lado de quem FAZ e não de quem USA, isto é um fato.

5. O uso de frameworks / libs é uma questão de escolha, não é obrigatório; você decide qual utilizar e SE VAI UTILIZAR; se o resultado não foi tão bom como esperava o erro tambem está em você. Boa parte dos frameworks disponibiliza o código fonte, precisa dizer algo mais?

6. Negligenciar nas decisões, nas escolhas nos estudos e posar de vítima é fraco tente evitar chegar a este ponto.

7. Se meter em computação APENAS por dinheiro dá nisso.

…

flws

Só não concordo mais de 100% porque não da…

Desabafo anti troll

Nossa, quando o Vini me falou que a discussão estava pegando fogo por aqui, eu imaginei que as pessoas estavam discutindo sobre o artigo, e não sobre a minha pessoa. Bacana ver que muitos não sabem argumentar com um artigo sem atacarem o autor.

Sinceramente, é tudo muito bacana e bonito quando você tem TEMPO para estudar algo a fundo. Tudo faz mais sentido. Eu estou aprendendo Lisp e Python com toda a calma do mundo e, nossa, como é agradável.

Agora, experimenta trabalhar meio período no qual você tem de entender o que querem que você faça, estudar meia dúzia de tecnologias e apresentar coisas no final do mês QUANDO VOCÊ É A ÚNICA DESENVOLVEDORA DO TIME. Na época eu entendia de Hibernate, pelo menos o suficiente, e estava aprendendo web services, e já tinha trabalhado com Java antes. Mas tive de pesquisar e aprender sobre BPMN, BPEL, descobrir o Liferay, como mexer no Liferay, entender um dos módulos do Liferay, como mexer nele, descobrir que ele usava Struts, como funcionava Struts, e nesse meio tempo ainda fazer prototipos para eu e meu orientador nos entendermos. Eu acordava cinco e meia da manhã de vez em quando porque tinha me tocado como resolver um problema que eu tinha passado dez horas do dia anterior tentando resolver.

Eu gostaria de ter tido a opção de dizer “olha, vou ali estudar tudo o que preciso direitinho e na ordem certa, volto daqui a uns seis meses”, mas não era uma opção, assim como não era fazer um portlet do zero pq eu já não tinha mais tempo.

Desculpa, mas eu não esperava que um texto que era um desabafo pessoal fosse ser usado para que as pessoas tivessem opiniões completamente distorcidas sobre o que eu faço e como eu trabalho.

E não me façam rir, se meu negócio fosse dinheiro (e só dinheiro) eu não estaria programando, pelo amor de deus.

Sim, eu sou inexperiente, como diabos eu teria muita experiência se eu só tenho 22 anos e só voltei a trabalhar com programação nos últimos dois anos? Mas certamente não comecei a programar ontem, e eu acho que mereço respeito mesmo ainda sendo, seilá, Júnior e não a mega boga master programadora ever.

E o Hibernate é bom, mas não o suficiente. Estou começando a ver coisas como NoSQL para ver se existem alternativas melhores. Hibernate já me salvou a pele algumas vezes, é sensacional quando EU estou fazendo a coisa a partir do zero. Talvez eu gostasse de Struts se eu estivesse desenvolvendo algo a partir do zero com ela e, olhando em retrospecto, talvez eu devesse ter feito isso. Mas sabe de uma coisa? Não tinha ninguém para me dar os passos certos, eu tinha alguns colegas, mas eles estavam em outros projetos e não podiam fazer muito além de dar uma ou outra dica (que em alguns salvaram algumas noites de sono, diga-se de passagem), mas na maior parte era um “quero isso, te vira”. E eu não sou a única, se alguém aqui já trabalhou em laboratório de faculdade talvez já tenha passado por algo parecido.

Fim do desabafo anti troll

O que me irrita em muitas frameworks é quando elas deixam o trabalho do primeiro programador mais fácil e o do segundo trabalhador um inferno. Eu passei SEMANAS até entender decentemente a estrutura de um mísero portlet que grava informações num banco, mostra na tela, dá algumas opções para o usuário…

Agora, me digam os grandes senhores do Java, isso é normal ou fui eu quem encontrei código macarronico pela frente?

Método (X argumentos)
Método(X - 1 argumentos) -> seta o outro argumento e chama o método anterior
Método(X - 2 argumentos) -> seta os argumentos e chama o primeiro método
…

Sério, QUE PORQUICE.

Ou então uma parte que tinha umas mil interfaces e blablabla, era redirecionamento para tudo quanto é lado até chegar onde você quer. DRY prá que te quero.

Algumas pessoas não entenderam exatamente o que eu quis dizer.

Eu NÃO falei que nós não deveríamos ter bibliotecas.

Eu NÃO falei que nunca deveríamos usar frameworks, ou até mesmo geradores de código - eu já usei alguns geradores para mapear tabelas e não tive problema alguma porque era um código simples e que eu sabia ler e mudar o que precisasse (tive um problema com um dos mapeamentos, mas foi dos menores problemas q eu tive no projeto :p) e sei como isso economiza tempo.

Minha crítica é quando a biblioteca/framework/API deixa de te economizar tempo e começa a aumentar o tempo para o coitado da manutenção que vai ter de ler métodos de nomes estranhos com redirecionamentos infinitos. Imaginem a vida do coitado que vai fazer uma modificação em um dos métodos e tem de passar um tempão estudando a framework para não quebrar o negócio inteiro… (mesmo que a pessoa entenda mto bem sobre fazer java para web, mas coitada dela senao tiver trabalhado com AQUELA framework em especial…)

Minha crítica é que, ainda que existam frameworks que estejam ajudando a tratar de problemas complexos, em muitos casos elas o fazem de maneira o código complicado de maneira quase exponencial!

Por isso agora que eu não estou mais em nenhum projeto eu dei vários passos para trás e estou voltando para as bases. Estou lendo o SICP para abrir meus horizontes e estudar algoritmos a fundo, estou aprendendo Python para conhecer uma linguagem que se aproxima muito mais do que eu considero agradável de se programar.

Por fim, para aqueles que disseram que sou inexperiente, que estou reclamando a toa…

Olha, nao sou NEM DE LONGE a única a pensar assim. O próprio Vini que abriu o tópico concordou comigo, e ele tem muitos anos de estrada com isso.

Eu não sou a única a querer APIs melhores: http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext (esse texto me fez ver também que eu nunca quero trabalhar com .NET, -_-)

Aliás, sobre esse texto, acho que ele explica melhor do que eu sobre o que eu chamei de “bandaids”: algo de base não funciona como deveria, e vai-se tentando remediar isso… mas sempre são bandaids e, como tal, problemáticos. Muitos problemas seriam evitados se fosse possível escolher a linguagem mais adequada para o problema, para começo de conversa, já que em algumas linguagens certas resoluções são triviais em vista do que se tem em outras linguagens.

Nem a única que se “desencantou” com certos cenários do mercado atual: http://reprog.wordpress.com/2010/03/03/whatever-happened-to-programming/ (esse me deixou mto feliz quando li, foi algo como “UAU, não sou só eu quem me sinto assim, talvez o problema não seja só comigo”.)

Como já falei, meu texto era um desabafo, e só isso. Para talvez dar para alguém a mesma sensação que eu tive de 'UFA NÃO É SÓ COMIGO" que eu tive ao ler o texto “Whatever Happened to Programming?”, e eu achei muito bacana ver relatos parecidos com os meus, assim como indicações e dicas do que fazer.

E, ufa, acho que respondi tudo o que eu queria. Eu acho.

(eu tenho uma certa dificuldade em escrever textos pequenos, sorry)

Após ler o texto, ou melhor, até ler quase o final, pois nao consegui terminar de ler…

a minha humilde opinião:

Nao gosto de pessoas negativas, que texto mais negativo! trabalho há 5 anos com java e ja tive o prazer de trabalhar em otimos projetos…

Pedras no caminho? é claro que teremos, a vida seria maravilhosa se nao existissem…

E aprendemos com nossos erros, crescemos e evoluimos, certo?

bom pelo meno eu penso assim… nunca curti trabalhar com pessoas que so ficassem reclamando, o que eu li foi uma reclamacao total, uma negatividade só, essa foi a minha opinião.

nos dediquemos mais e reclamemos menos.

“Perder menos tempo escrevendo textos longos, e sobrará tempo pra estudar mais…”

Olá miwi,

O foco é : 20 anos depois e ainda não entendemos reusabilidade.

Eu penso que temos boas ferramentas e aprendemos muito sobre reusabilidade. Mas uma coisa é certo o hibernate vai evoluir

e o JSF vai evoluir espero…Não existe framework que não tenha que melhorar, não existe código que não possa ser melhorado.

Esse é o ponto da questão. Mais uma vez gostei do Post espero que apareça mais posts no seu blog.

“Se escrevi esta carta tão longa, foi porque não tive tempo para fazê-la mais curta.” (Blaise Pascal).

MaiqueL:

Olá miwi,

O foco é : 20 anos depois e ainda não entendemos reusabilidade.

Eu penso que temos boas ferramentas e aprendemos muito sobre reusabilidade. Mas uma coisa é certo o hibernate vai evoluir

e o JSF vai evoluir espero…Não existe framework que não tenha que melhorar, não existe código que não possa ser melhorado.

Esse é o ponto da questão. Mais uma vez gostei do Post espero que apareça mais posts no seu blog.

Sim, eu ESPERO que essas ferramentas evoluam, assim como tantas outras. A questão é que evolução pode significar muitas coisas.

Por exemplo, eu acho bom que no Hibernate você tenha um arquivo XML com algumas configurações do banco de dados. Ele é um arquivo pequeno e é relevante ter aquelas informaçÕes com acesso rápido e simples. Mas hoje é comum você ver algumas frameworks que começam a usar XML para tudo, e o que deveria servir para deixar as informaçÕes mais legiveis acabam torcendo a coisa… muito confusa. E isso está gerando algumas pessoas com alergias a XML

E certas coisas que são ditas como "inovadoras’ hj em dia já eram ensinadas há vinte anos. Outras não, mas a questão é que, por não estudarmos certas bases importantes, nós acabamos por repetir erros que poderiam ser evitados.

(e digo isso com Mea Culpa, mas pelo menos eu estou correndo atrás do atraso :p)

“Se escrevi esta carta tão longa, foi porque não tive tempo para fazê-la mais curta.” (Blaise Pascal).

[/quote]

Concordo plenamente

Para a pessoa que achou o texto muito negativo… bom, era um desabafo depois de uma grande frustração. Não deu para evitar, ao menos nesse texto

miwi

vc fala tanto quanto escreve?

Deus me livre! :roll:

FrancoC:

miwi

vc fala tanto quanto escreve?

Deus me livre! :roll:

Bom… a minha opinião começou a mudar de fato depois de ler as suas respostas.
Quando você atinge as ferramentas que geram código e os duzentos mil arquivos xml de configuração, concordo com você. O Axis2, por exemplo, gera um baita código que fica difícil de entender. É um ponto negativo, mas tem um ponto positivo: ele cuida de tudo pra você. Até que alguém precisa mudar alguma coisa lá… Daí o bixo pega. Só que vai dizer que é mais fácil usar JAX-WS pra consumir um webservice… Não tem como falar uma coisa dessas depois de você tentar a usar o Axis2! O Axis2, mesmo gerando tanto código ruim de ler, é ainda a melhor solução (dependendo do ponto de vista) pra se chegar rápido ao que se deseja. E eu, pelo menos, ainda não tive que mexer no código que foi gerado (pelo menos não detalhadamente), o que mostra que a robustez dele é um tanto quanto positiva. Claro, existem outras alternativas (como o GXF, ex- XFire) que são melhores comentadas por alguns desenvolvedores atualmente.

Também, configurar vários arquivos XML pra fazer um framework funcionar é horrível (ou até mesmo configurar um servidor). Quando digo vários, não entendam a JPA com Annotations, que vieram a facilitar muito o trabalho do programador.

Outra coisa que deve ser advertida é o uso de jars em tudo. Pega-se tudo, não sabe como funciona, junta e pronto. Tá vendendo o negócio… Até que dá um problema ali e outro acolá. Daí o mundo desaba sobre a cabeça do pobre coitado. Certo?

Desabafo anti troll

Nossa, quando o Vini me falou que a discussão estava pegando fogo por aqui, eu imaginei que as pessoas estavam discutindo sobre o artigo, e não sobre a minha pessoa. Bacana ver que muitos não sabem argumentar com um artigo sem atacarem o autor.

Sinceramente, é tudo muito bacana e bonito quando você tem TEMPO para estudar algo a fundo. Tudo faz mais sentido. Eu estou aprendendo Lisp e Python com toda a calma do mundo e, nossa, como é agradável.

Agora, experimenta trabalhar meio período no qual você tem de entender o que querem que você faça, estudar meia dúzia de tecnologias e apresentar coisas no final do mês QUANDO VOCÊ É A ÚNICA DESENVOLVEDORA DO TIME. Na época eu entendia de Hibernate, pelo menos o suficiente, e estava aprendendo web services, e já tinha trabalhado com Java antes. Mas tive de pesquisar e aprender sobre BPMN, BPEL, descobrir o Liferay, como mexer no Liferay, entender um dos módulos do Liferay, como mexer nele, descobrir que ele usava Struts, como funcionava Struts, e nesse meio tempo ainda fazer prototipos para eu e meu orientador nos entendermos. Eu acordava cinco e meia da manhã de vez em quando porque tinha me tocado como resolver um problema que eu tinha passado dez horas do dia anterior tentando resolver.

Eu gostaria de ter tido a opção de dizer “olha, vou ali estudar tudo o que preciso direitinho e na ordem certa, volto daqui a uns seis meses”, mas não era uma opção, assim como não era fazer um portlet do zero pq eu já não tinha mais tempo.

Desculpa, mas eu não esperava que um texto que era um desabafo pessoal fosse ser usado para que as pessoas tivessem opiniões completamente distorcidas sobre o que eu faço e como eu trabalho.

E não me façam rir, se meu negócio fosse dinheiro (e só dinheiro) eu não estaria programando, pelo amor de deus.

Sim, eu sou inexperiente, como diabos eu teria muita experiência se eu só tenho 22 anos e só voltei a trabalhar com programação nos últimos dois anos? Mas certamente não comecei a programar ontem, e eu acho que mereço respeito mesmo ainda sendo, seilá, Júnior e não a mega boga master programadora ever.

voce ainda nao viu nada pelo menos esses frameworks tem vasta documentação e comunidades agora imagine tu chegar em uma consultoria que trabalha para o bradesco por exemplo e ter usar um framework proprietario
sem documentaçao nenhuma
com um plugin horrivel
sem treinamento
e os caras falarem “se vira” a data e XX/XX/XXXX

dai tu tem sair procurando e perguntando e se virando… por que pois nessas porcarias tem coisas importantes encapsuladas,testadas e homologadas, eles não querem saber se e dificil ou não.

por isso que no apinfo tu olha um vaga e tem 900 requerimentos… por que se o cara não tiver uma noção so saber o basico não serve.

se ruim com frameworks pior sem eles, a não ser que se faça o software da padaria da esquina dai qualquer um confia em um iniciante.

Eu sinto muita falta dessa liberdade mais infelizmente ela não existe na maioria dos casos, por isso eu adotei a seguinte filosofia trabalho por grana como se fosse um caixa de supermercado e so fazer a mesma tosqueira todo dia que ta na conta no fim do mes.

Faço projetos pessoais como jogos entre outros… por diversão e prazer em casa, ate estudar e ter experiência o o suficiente para ser arquiteto ou algo mais “legal”.

rodrigo.lopes:

Após ler o texto, ou melhor, até ler quase o final, pois nao consegui terminar de ler…

a minha humilde opinião:

Nao gosto de pessoas negativas, que texto mais negativo! trabalho há 5 anos com java e ja tive o prazer de trabalhar em otimos projetos…

Pedras no caminho? é claro que teremos, a vida seria maravilhosa se nao existissem…

E aprendemos com nossos erros, crescemos e evoluimos, certo?

bom pelo meno eu penso assim… nunca curti trabalhar com pessoas que so ficassem reclamando, o que eu li foi uma reclamacao total, uma negatividade só, essa foi a minha opinião.

nos dediquemos mais e reclamemos menos.

“Perder menos tempo escrevendo textos longos, e sobrará tempo pra estudar mais…”

Não leu até o fim só porque o texto era crítico?

Mas entendo que, trabalhar no mercado Java hoje em dia é passar raiva, ainda tem que aturar esse povo falando em Python e SICP.

Não concordo com essa afirmação 100%. Determinados frameworks tem N configurações porque não resolveram o problema de maneira genérica. É o caso do Hibernate, que é um framework simplista.

O problema é: mapear entidades, essas entidades possuirão pk e fk. Acabou o problema.
A solução simplista (hibernate): Duzentos tipos diferentes de mapeamento, um para cada situação.
A solução ideal: Uma forma de informar ao framework como efetuar o mapeamento, ex: Essa classe vc mapeia com essa por meio de um fk assim. Certo, isso é um ManyToOne. Numa solução ideal, voce poderia ter um alias ManyToOne que significa essa forma de mapeamento. E ainda tem a liberdade de configurar outro relacionamento mais complexo, caso exista na sua aplicação. No hibernate, voce só tem os mapeamento pré-definidos, ou seja, solução simplista.

Se o framework X tem N configurações também pode ser, porque ele não é genérico o suficiente, como disse anteriormente.

Eu nao sei o que quis dizer com manipular dados na época da programaçao estruturada. Mas se usar JDBC, talvez com um wrapper simplificador para suas necessidades, seria a mesma coisa não?
Se o desenvolvedor da aplicação não inventar milhões de relacionamentos complicados, acho que é fácil persistir hoje… Basta criar uma classe entidade, load, save, delete… Até uma solução caseira resolve

O maior bandaid que eu conheço chama-se JBoss Seam. O objetivo do JBoss Seam é permitir o uso de EJB e JSF de forma praticável, pois utilizar essas duas tecnologias, é um pequeno parto de uma criança verde. Então o JBoss Seam, tenta melhorar essa situação. Por isso muita gente o idolatra, como a salvação da pátria… ehehhe

Uma programação bem feita, e com bom reaproveitamento, seria sim, juntar várias peças de lego.
Já reparou como o Lego é bem feito e todas as peças se encaixam?! Inclusive de várias formas diferentes?
O problema é que as peças computacionais ainda não chegaram ao nível do Lego.
Talvez, os arquitetos brincaram pouco de lego quando eram crianças.

O ideal é que um framework te permita trabalhar com um aprendizado porco de 5 minutos, para pelo menos fazer o básico. Você depois estuda o livro pra saber algo mais especializado. Mas esse novo aprendizado, não deveria fazer com que jogasse a sua aplicação de 5 minutos fora e fazer de outra forma.

A resposta para essa pergunta não é apenas uma. Podem ser vários motivos.

• Esse que você citou
• O cara quis fazer um framework porque ele achou legal
• As soluções existentes não atendem da forma desejada ou não atendem completamente
  Afinal, porque Rod Johnson criou o Spring? Porque ele não conseguiu usar o EJB? Garanto que não…

Se o hibernate numa situação hipotética fosse abandonado hoje, seria um problema real? Não, não seria. Ele te atende, tem documentação e fonte. Tendo isso, não importa se ele tem 10 anos ou 1.
Alguém que teve essa opinião a um tempo atrás, usou o hibernate antes de todo mundo.
Eu usei o Spring quando ele estava nascendo, me importava se ele era novo? Não! Ele me atendia, tinha documentação e fonte. Se ele fosse abandonado, não deixaria de me atender.

Complicado é ter uma solução simples para permitir isso. Mas fazer essa mágica é até relativamente bem simples. Com o web fragments, será possível agora finalmente eliminar até o web.xml

Num bom framework, e se vc mantiver o desenvolvimento de sua aplicação de forma simples. Ao invés de inventar moda. Talvez vc consiga chegar ao final do desenvolvimento, sem nem ter que mudar esse pingo.

E são entusiastas também. Principalmente com o que é padrão. Aí usam sem saber o que tão fazendo, e acreditando que aquilo é a melhor coisa do mundo, na maioria das vezes não conhecem outra coisa.
Eu também já fui um pouco assim eheheheh
Mas mudei de opinião ao ver com o que realmente estava mechendo…

Esse aqui eu apenas… concordo!

Relaxa, o que o povo falou nem foi tão troll assim.
Já participei de discussões onde neguinho só postou pra falar que meu post era inútil. Onde o cara faz uma pergunta e não aceita que alguém que respondeu tenha o conhecimento. E até argumentações utilizando ets e groselha. :shock:

MaiqueL:

Mas uma coisa é certo o hibernate vai evoluir
e o JSF vai evoluir espero

Tem anos que o Hibernate é a mesma coisa… O JSF desde a primeira versão estão tentando fazer funcionar. Há!! Esse problema, agora na versão XX, vai estar resolvido…
O pessoal tá mais preocupado em fazer uma camada, com super arquitetura, sobre algo que já existe e não vai mudar a vida de ninguém, do que resolver os problemas existentes ou fazer novos features.

O pior é quando não se reconhece que existe o problema. Ou então quando se reconhece, continua insistindo… Na filosofia: Agora vai!!!

É fácil perceber o comportamento de um Framework ou ferramenta, pela intenção dele.
Se tiver a intenção de simples e unicamente ganhar dinheiro com a ferramenta, pode saber, que vai sair um lixão.
Se tiver a intenção de criar uma super arquitetura, que só o arquiteto entende, deve ser utilizado pelos que acreditam que o arquiteto sabe. Afinal, ele é o arquiteto. Provavelmente, será burocrático, e gastará umas duas horas para se fazer um Hello World!
Se tiver a intenção de trazer uma solução para um problema existente e comum. Entendendo que trazer solução, é resolver o problema, e não trocar o problema do usuário por um outro diferente. Esse sim, tem grandes chances de ser uma excelente ferramenta.

Para se perceber isso… é necessário ter experiência e visão. Ser curioso, fuçar, estudar, olhar o fonte, debugar, imaginar como foi implementado.
Com essas características é possível separar o joio do trigo, e escolher boas ferramentas que possibilitarão um bom sistema. E inclusive numa equipe onde a maioria dos desenvolvedores é júnior.
Se existem ferramentas ruins, é porque tem gente que “compra”. E quem compra tem a certeza de que está escolhendo o melhor, e nem vê os problemas que estão na frente do nariz.
Ser crítico e não ter religiosidade sobre a ferramenta de trabalho, é um importante passo para enxergar soluções disponíveis e possuir uma boa arquitetura.
Essa visão, crítica, e questionamento que a nossa colega teve é fundamental para a evolução.
Dou meus parabéns a [color=darkblue]miwi [/color]pelo pensamento, visão e questionamento de porque tem que dar tanto trabalho?!

rogelgarcia:

Eu nao sei o que quis dizer com manipular dados na época da programaçao estruturada. Mas se usar JDBC, talvez com um wrapper simplificador para suas necessidades, seria a mesma coisa não?
Se o desenvolvedor da aplicação não inventar milhões de relacionamentos complicados, acho que é fácil persistir hoje… Basta criar uma classe entidade, load, save, delete… Até uma solução caseira resolve :D

Não resolve. Porque você terá que transformar os dados em objetos. Sem isso, você estará programando da maneira incorreta, e recairá em problemas piores. Afinal, o paradigma em volta da sua solução ainda é o OO. Mas na época da estruturada, o programa era organizado em torno dos dados, não das entidades. E uma das grandes vantagens disso, é que era simples fazer manipulação direta das coisas, ao custo de uma visão menos direta do modelo de negócios.

Não estou falando que estruturada é melhor que OO, acho que esse é um dos poucos aspectos que eu considero nesse sentido. E hoje não é fácil persistir. Num sistema minúsculo de video-locadora talvez, mas em aplicações de verdade, não tem como ficar no simples entidade, load, save e delete. Até pq vc terá relacionamentos como heranças, acoplamentos de listas e outras coisas que ficam complicadas de se representar diretamente no modelo relacional.

Franco, as duas críticas que vc fez, atacando diretamente o texto e a autora, não tiveram uma argumentação sequer.
Se vc quiser continuar só na agressão, sugiro que se retire da discussão. Você não é obrigado a ler o tópico.

ViniGodoy:

Não estou falando que estruturada é melhor que OO, acho que esse é um dos poucos aspectos que eu considero nesse sentido. E hoje não é fácil persistir. Num sistema minúsculo de video-locadora talvez, mas em aplicações de verdade, não tem como ficar no simples entidade, load, save e delete. Até pq vc terá relacionamentos como heranças, acoplamentos de listas e outras coisas que ficam complicadas de se representar diretamente no modelo relacional.

Entendi o que voce quis dizer… para fazer a persistenica, eu uso hibernate, mas não 100% de acordo com a cartilha dele… justamente para evitar alguns problemas que está citando…
Mas isso fica para outra discussão

Franco, as duas críticas que vc fez, atacando diretamente o texto e a autora, não tiveram uma argumentação sequer.
Se vc quiser continuar só na agressão, sugiro que se retire da discussão. Você não é obrigado a ler o tópico.

Faz parte!!

Em se falando de hibernate, temos um problema serio, como o Java é Tipificado, e não podemos criar campos em tempo de execução em uma classe (Sim, tem, mas ninguem é loco de ficar usando javassist a torto e adireita, e mesmo assim não é nativo), a solução mais elegante é o ActiveRecord do Rails, na minha opnião, você não se atem a detalhes da base, só se preocupa com detalhes do objeto, tratar os dados, não fica aquele monte de Anotações ou XML.

Acredito que as vezes a complexibilidade está logicamente na propria linguagem, existem alguns pontos que o java não é flexivel como outras linguagens, isso nos força a encontrar um meio de equilibrio entre as partes para utiliza-los.

Eu trabalhei num laboratório de informática da faculdade, mas era diferente, tinham um certo tempo (diga-se bom tempo), para ficarmos estudando, quando as demandas de projetos aumentaram e eu pulei fora, pois meu conhecimento estava fora do salario que me pagavam.

O detalhe, é que também sempre achei o desenvolvimento em Java (Usando Hibernate, Spring), muito chato e tedioso, levava uma tarde para mapear as entidades de um projetinho rediculo, até tentei criar um gerador para suprir minhas necessidades, mas encontrei tantos disponiveis, que acabei não usando nenhum. Até fiquei contente enquanto lia as definições do Spring, finalmente eu posso configurar meu DataSource em Java, sem XML, e é logico com annotations, do jeito que essas annotations vem crescendo vamos acabar fazendo em XML por que vai ficar mais legivel.

Eu não acho o fim do mundo configurar xml não, para quem já trabalhou para uns bancos ai, xml do hibernate é moleza… Não tem outra thread onde o pessoal vai fazer um “desafio” e desenvolver algo em equipe? Não acompanhei tudo, mas tem várias páginas lá, acredito que algo esteja rolando. Pq não aproveitam e tentam desenvolver uma solução que elimine parte destes problemas?

Porque quem desenvolve soluções para Java provavelmente já se deu conta que não vale a pena o esforço, já que se trata de uma fraqueza da linguagem utilizada, o problema não está no XML ou nos frameworks. Existem ótimas bibliotecas Java por ai, mas se vc anda precisando de muito XML ou frameworks web na sua aplicação Java, talvez fosse melhor servido por uma linguagem dinâmica para JVM.

Felagund:

Em se falando de hibernate, temos um problema serio, como o Java é Tipificado, e não podemos criar campos em tempo de execução em uma classe (Sim, tem, mas ninguem é loco de ficar usando javassist a torto e adireita, e mesmo assim não é nativo), a solução mais elegante é o ActiveRecord do Rails, na minha opnião, você não se atem a detalhes da base, só se preocupa com detalhes do objeto, tratar os dados, não fica aquele monte de Anotações ou XML.

Creio que o problema não está em escrever os campos, e sim, realizar os mapeamentos ORM. Mesmo com o ActiveRecord, a aplicação continua sendo OO, e o banco relacional.

Um dos problemas que vejo no hibernate é que ele é incompleto e a forma de mapeamento é errada. Exemplo, quando mapeamos um relacionamento @OneToMany. Já definimos no mesmo lugar como é feito o mapeamento e como é feita a persistencia.
Os problemas disso são:

• A forma de mapear, e a forma de persistir, são duas coisas diferentes, logo não deveria estar tudo em apenas uma única anotação.
• O outro problema é que vc define a forma de persistir estaticamente, ou seja, vc só poderá usar essa forma de persistir. Se tiver duas situações no seu programa, o que é comum, onde em um lugar se deseja persistir de uma forma, e em outro lugar de outra forma dependendo da regra de negócio, não será possível.

Por isso sempre faço os mapeamentos não deixando o hibernate fazer nada de persistencia de forma automática, porque isso não funciona. Ao invés disso, executo códigos para persistir de acordo com a necessidade do meu sistema, quando for necessário. Acho que isso resolve alguns problemas que o vini citou…

MaiqueL:

Grinvon:

MaiqueL:

Com relação a burocracia das ferramentas, eu penso o seguinte, o Hibernate por exemplo ele elimina da mão do programador muita coisa.

Existe burocracia pq existe muita complexidade a ser tratada.

Porém só temos o O/RM pq alguém não estava contente com a solução que existia na época.

O hibernate não elimina a complexidade, ele elimina a “repetição de rotinas”, e só isso, a complexidade continua existindo, mesmo sendo de outra forma. O seu ponto tá certo!

sem comentários…

Sinceramente, posso estar equivocado, mas entendi o seu comentário como crítica. Então eu queria saber em que ponto falei besteira?

De fato o hb/jpa ajuda e muito na crianção e manutenção das estruturas das tabelas, seja usando DDL ou MDL. Por tentar “simular” ORM, ele faz com que algumas coisas fiquem mais intuitivas, porém, a complexidade existe sim, só que agora ela tem outro nome.

Quem nunca teve problema com detached mode? Quem nunca tentou implementar um generic key no HB e conseguiu fazer funcionar muito bem de primeira, de segunda, de terceira…? Sabia que Listeners têm bugs que faz com que você não possa aproveitar uma sessão ativa neles e o JPA abafa o caso? Tendo que criar sempre sessões novas. E quando se fazia os joins, tentou fazer de forma bilateral para ver como ficava? A joça que você precisa fazer ao qual na estrutura “native” não tem esse problema. E coisas simples como o @OneToMany, onde o JPA dava pau na persistência de um elemento associado, ao qual a sua forma de salvá-lo deveria ser o adicionando exclusivamente na lista e persistinto a entidade mãe? Tudo bem que esse último aspecto não é um bug, mas limita a ação do desenvolvedor.

Agora a pergunta. Vale a pena usá-lo ao invés do tradicional modelo de JDBC como conhecemos? Sim. Por fatores que já foram mastigados em dezenas de tópicos aqui. Acredito que a solução hb/jpa é muito viável e é um framework com uma importância ultra.

Ainda não trabalhei com JPA 2.0. Li algumas artigos somente e vou fazer uso dele como teste, já que aqui no trabalho, não irei conseguir colocá-lo em prática por algum tempo.

E o meu conceito de framework segue a mesma lógica que a de miwi (ao menos no que entendi do que ela queria dizer). Um framework tem que ser simples para ser também chamado de framework e mesmo com a sua simplicidade, não poderá limitar as ações do desenvolvedor.

O Vini é um dos usuários mais bacanas aqui do forum, tem um tremendo bom senso e ajuda bastante quem precisa; sempre leio os post dele. Ele certamente achou que o artigo iria render uma boa discução e aprendizado, como de fato rendeu.

Porisso tenho certeza que ele sabia que a autora iria receber criticas positivas e tambem negativas pois muitos do forum “não passa a mão na cabeça” mesmo; claro que depende do que se escreve e como se escreve.

Para se atingir um nivel adiante é preciso saber receber criticas e aprender com elas, parabéns Vini por mais esta atitude espero que seja bem aproveitada.

Aos que gostam do Hibernate (eu me incluo), sejamos honestos, o framework é muito bacana mas se prestarmos atenção podemos perceber que é uma saida maluca para uma coisa que ainda não rolou - Não temos banco de dados orientado a objetos que tenha relevancia / credibilidade no mercado ainda.

Quando o banco de dados OO for uma realidade absoluta, iremos colocar estas coisas no fundo do baú e chama-las de GAMBI, tenho certeza disto.

P.S “Uma carta bem escrita e um código bem elaborado tem uma coisa em comum; a sintese” by eu mesmo.

flws

rogelgarcia:

Felagund:

Em se falando de hibernate, temos um problema serio, como o Java é Tipificado, e não podemos criar campos em tempo de execução em uma classe (Sim, tem, mas ninguem é loco de ficar usando javassist a torto e adireita, e mesmo assim não é nativo), a solução mais elegante é o ActiveRecord do Rails, na minha opnião, você não se atem a detalhes da base, só se preocupa com detalhes do objeto, tratar os dados, não fica aquele monte de Anotações ou XML.

Creio que o problema não está em escrever os campos, e sim, realizar os mapeamentos ORM. Mesmo com o ActiveRecord, a aplicação continua sendo OO, e o banco relacional.

Um dos problemas que vejo no hibernate é que ele é incompleto e a forma de mapeamento é errada. Exemplo, quando mapeamos um relacionamento @OneToMany. Já definimos no mesmo lugar como é feito o mapeamento e como é feita a persistencia.
Os problemas disso são:

• A forma de mapear, e a forma de persistir, são duas coisas diferentes, logo não deveria estar tudo em apenas uma única anotação.
• O outro problema é que vc define a forma de persistir estaticamente, ou seja, vc só poderá usar essa forma de persistir. Se tiver duas situações no seu programa, o que é comum, onde em um lugar se deseja persistir de uma forma, e em outro lugar de outra forma dependendo da regra de negócio, não será possível.

Por isso sempre faço os mapeamentos não deixando o hibernate fazer nada de forma automática porque isso não funciona. Ao invés disso, executo códigos para persistir de acordo com a necessidade do meu sistema, quando for necessário. Acho que isso resolve alguns problemas que o vini citou…

Rogel,

acabou de me ocorrer que o ActiveRecord não é transparente, ele faz muita coisa por baixo dos panos, deixa mais agil, porém vc não faz ideia do que ocorre.

Seguindo a sua definição teriamos mais uma anotação, ou seja, mais uma configuração, cada vez mais complexo e trabalho, menos prático.

Você faz sua própria persistencia? Não utiliza o Hibernate? Acho que não compreendi muito bem o ultimo paragrafo.

Felagund:

Rogel,

acabou de me ocorrer que o ActiveRecord não é transparente, ele faz muita coisa por baixo dos panos, deixa mais agil, porém vc não faz ideia do que ocorre.

Seguindo a sua definição teriamos mais uma anotação, ou seja, mais uma configuração, cada vez mais complexo e trabalho, menos prático.

Você faz sua própria persistencia? Não utiliza o Hibernate? Acho que não compreendi muito bem o ultimo paragrafo.

No caso, a ideia é que o mapeamento fosse genérico como citei no primeiro comentário, e houvesse uma forma de definir separadamente o que é mapeamento e o que é persistencia… Então poderia ser feito um alias, usando apenas uma anotação.
Mas seguindo a minha definição eu considero que nenhuma anotação é necessária.

package entity; //poderiamos definir que todas as classes do pacote entity são entidades

public class Pessoa {
      private Integer id; //id será o PK da classe sempre
      private Municipio municipio; // se municipio é outra entidade, é lógico que o relacionamento é ManyToOne
      private List<Documento> documentos; //aqui é lógico que existe um relacionamento oneToMany
}

Todas as informações estão na classe, logo nenhuma anotação deveria ser necessária.
Vc só usaria anotações para explicar algo que não fosse padrão, como um relacionamento mais complicado.

Eu considero também que a forma de persistir não deve ser definida estaticamente.
Exemplo:

@OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER)

Se vc definir isso estaticamente, se houver duas situações diferentes no seu sistema, onde em uma não se deseja esse comportamento, voce terá um problema.

Na hora de carregar e salvar, é que deve ser indicado, se deseja ou não carregar ou persistir outras entidades. Isso não é referente ao mapeamento da classe, portanto nao deve estar em anotações na classe.

Eu uso o hibernate para fazer o mapeamento, mas não uso cascade ou fetch eager…

Se desejo carregar outro objeto na mesma query faço left outer join fetch

E para salvar listas tenho uma classe que faz isso pra mim, meu código fica mais ou menos assim:

save(pessoa) .saveCollection("documentos")

fantomas:

miwi:

…
Fim do desabafo anti troll

O Vini é um dos usuários mais bacanas aqui do forum, tem um tremendo bom senso e ajuda bastante quem precisa; sempre leio os post dele. Ele certamente achou que o artigo iria render uma boa discução e aprendizado, como de fato rendeu.

Porisso tenho certeza que ele sabia que a autora iria receber criticas positivas e tambem negativas pois muitos do forum “não passa a mão na cabeça” mesmo; claro que depende do que se escreve e como se escreve.

Para se atingir um nivel adiante é preciso saber receber criticas e aprender com elas, parabéns Vini por mais esta atitude espero que seja bem aproveitada.

Aos que gostam do Hibernate (eu me incluo), sejamos honestos, o framework é muito bacana mas se prestarmos atenção podemos perceber que é uma saida maluca para uma coisa que ainda não rolou - Não temos banco de dados orientado a objetos que tenha relevancia / credibilidade no mercado ainda.

Quando o banco de dados OO for uma realidade absoluta, iremos colocar estas coisas no fundo do baú e chama-las de GAMBI, tenho certeza disto.

P.S “Uma carta bem escrita e um código bem elaborado tem uma coisa em comum; a sintese” by eu mesmo.

flws

Hibernate não rolou? Achei que fosse o framework mais utilizado nas empresas…

Banco de dados OO é uma realidade. O unico problema é que a gambiarra é muito maior que no hibernate. Ferramentas ORM delegam toda a complexidade de gerenciar o banco de dados para o SGBD que estiver configurado. Banco de dados OO vc tem que implementar o seu próprio SGBD. E fazer isso usando locks de objeto é sujeito a soluções complexas e por isso propricio a bugs e performance inaceitável.

Oi mochuara,

Rolar, rolou; eu uso, gosto e no momento acredito ser a melhor resposta.

Mas aí é que está…só rolou porque não tem um banco de dados OO DE FATO talvez por conta do que você mesmo disse.

flws

Gostei dessa sua abordagem, seria realmente algo muito interessante de ser feito.

Felagund:

rogelgarcia:

Todas as informações estão na classe, logo nenhuma anotação deveria ser necessária.

Gostei dessa sua abordagem, seria realmente algo muito interessante de ser feito.

O JPA já não faz isso?
Pelo que eu me lembro, se o atributo tiver o mesmo nome do campo na tabela não é preciso anotação.
Isso só não ocorre para a PK e os relacionamentos.

juliofsn:

Felagund:

rogelgarcia:

Todas as informações estão na classe, logo nenhuma anotação deveria ser necessária.

Gostei dessa sua abordagem, seria realmente algo muito interessante de ser feito.

O JPA já não faz isso?
Pelo que eu me lembro, se o atributo tiver o mesmo nome do campo na tabela não é preciso anotação.
Isso só não ocorre para a PK e os relacionamentos.

Não, precisa sempre ter a anotação.

Olá, já vou avisando que não li todos os posts.
Parabéns o Vini por postar o link do Blog e parabéns a miwi pelo Blog e pelo post propriamente dito (já coloquei ele no meu reader, apesar de não usar tanto o reader como eu gostaria…). Não ligue para os trolls, como o GUJ tem se tornado a cada dia uma comunidade cada vez maior, a proporção de sujeira (maus usuários, posts nonsense) também aumenta.

Minha opinião: eu concordo com a miwi. A gente demora um tempão para fazer as coisas funcionarem e ficamos totalmente amarrados aos malditos arquivos de configuração. Se é difícil usar, imagina escolher qual usar. Falaram de qualidade, que bibliotecas e/ou frameworks que foram feitos por pessoas experientes são melhores e tal, mas sei lá, parece que tudo é sempre um rolo danado. É indiscutível a utilidade do Hibernate e do Spring, mas ainda sinto que falta ser mais simples. De que forma? Não sei. E os frameworks MVC? Caóticos. E sempre um novo aparece que só insere mais uma forma de fazer a mesma coisa. Parece que sempre a gente ta usando um canhão para matar um mosquito.

Quanto a geração de código, eu sinceramente acho que nem vale a pena discutir. Quer usar algo que gere código? Use, mas não se importe com o que vai ser gerado. Reclamam de código de IDE (que é sujo mesmo haha), mas vocês já viram o código que o antlr gera? Haha aquilo sim é uma doideira. Não que um parser precise ser totalmente legível (o que importa é a gramática se legível), mas também não precisa ser um lixo

Enfim, acho que essa é uma briga eterna, entretanto essas bibliotecas/frameworks/IDEs precisam melhorar sim. Pega alguém que usa todas as funcionalidades do Visual Studio ou Delphi por exemplo e manda fazer um cadastrinho em Java.

Meu post parece que ficou um pouco desconexo, mas acho que vocês conseguiram me entender

[]´s

Ótimo tópico e ótimo post da garota, ainda não li todo o tópico , depois leio com mais calma, vou só dar meu pitaco rapidamente.

Não sou desenvolvedor Java e sim .Net, e apesar de .Net não ter tantos frameworks quanto Java, possui alguns, mas pelo que observo em .Net o pessoal ainda costuma utilizar mais soluções Ad Hoc, pelo menos aqui onde trabalho é assim, sempre escrevemos nossos DAO’s na mão, utilizando apenas o ADO.NET.

Até que o pessoal aqui resolveu desenvolver um framework, meu que cagada, agora estou em um projeto, totalmente engessado nesse framework, com mal uso de tudo, e tendo que dar voltas para resolver problemas simples.

Eu realmente acho que geradores automáticos de código deveriam gerar código não editável. Como no caso do Builder, Delphi ou VB, que gera um arquivo binário para a tela, e que o programador nem sequer pensa em descompilar aquilo para entender como ele faz.

Se a proposta é fazer automaticamente, então, faça direito.
Se estou tendo que mexer no código na mão depois disso, é porque meu gerador não cumpriu bem o papel dele.

ViniGodoy:

Eu realmente acho que geradores automáticos de código deveriam gerar código não editável. Como no caso do Builder, Delphi ou VB, que gera um arquivo binário para a tela, e que o programador nem sequer pensa em descompilar aquilo para entender como ele faz.

Se a proposta é fazer automaticamente, então, faça direito.
Se estou tendo que mexer no código na mão depois disso, é porque meu gerador não cumpriu bem o papel dele.

Concordo em número, genero e grau.

Claro, código gerado não deve ser modificado, mas as vezes a gente quer entender alguma coisa.
Concordo com o Vini que não deveria ser modificado.

Concordo plenamente com a autora do texto, que, aliás, escreve muito bem.

Assim que comecei a estudar o Java, eu achei a linguagem maravilhosa, e acabei me tornando o típico Java fan boy. Mas com o tempo, e principalmente com experiência em projetos reais, eu percebi que as coisas não eram tão fáceis como eu achava (e ainda acho) que deveriam ser.

Nessas situações nós tendemos a nos culpar, questionando a nossa inteligência ou aptidão para a o programação, e naturalmente eu também passei por esse processo. Mas novamente o tempo passa, e eu acabei percebendo que eu não era tão burro quanto imaginava, e que provavelmente o problema não estava comigo.

Digo isso porque eu acabei tendo contato com outras tecnologias, sendo que todas elas obviamente também possuem seus problemas, mas algumas delas me pareceram consideravelmente mais simples que o Java em aspectos que me importavam, como desenvolver facilmente uma aplicação Web que faça as operações básicas no banco de dados.

Sei que o que vou dizer nessa frase pode ativar o flag trollarComoSeNaoHouvesseAmanha de alguns usuários do GUJ, mas eu acho que utilizar o Java para Web foi uma das piores idéias de todos os tempos.

Hoje eu não gosto mais de programar com o Java, mas admito que a linguagem tem seus méritos. No entanto, me parece que o Java simplesmente não foi feito para a Web, e nem poderia, já que a Web estava engatinhado quando iniciou-se o desenvolvimento do Java.

Eu sempre vi o Java como uma versão mais segura e amigável do C++, mas assim como esse último, me parece que tentar aplicar o Java para desenvolvimento Web era tentar usar algo antiquado e verboso em um ambiente mais dinâmico. Dá pra fazer, assim como dá pra criar aplicações Web com C++, mas não me parece uma boa idéia.

Uma analogia que eu sempre tive na minha cabeça é que o Java é música clássica, e a Web é uma festa. Ou seja, os dois simplesmente não combinam.

Ainda que a plataforma tenha obtido bastante sucesso no desenvolvimento Web, eu credito esse sucesso ao poder que a Sun tinha no início da década passada. Se pararmos pra pensar imparcialmente, o que eu sei por experiência própria que é difícil quando estamos apaixonados por uma tecnologia, veremos que a imensa maioria das aplicações Web que desenvolvemos em Java poderiam ser desenvolvidas com outras tecnologias mais simples, como Ruby on Rails, PHP e Python. E sem perdas.

Eu sei que o lado troll do típico Java fan boy diria que essas tecnologias são “quick and dirty”, que são toscas, que tornam a manutenção um parto, que não escalam pra mais do que meia dúzia de usuários, entre outras idiotices que contamos a nós mesmos para nossa tecnologia preferida não parecer inadequada em um dado cenário. Eu sei disso porque eu já estive nessa posição, e disse e pensei coisas que hoje eu acredito serem incrivelmente idiotas.

Mas a realidade é que essas tecnologias são sim adequadas para a maioria das aplicações Web, e também são perfeitamente capazes de produzir código limpo, fácil de manter, e com uma suite de testes abrangente. Basta lembrar que a maioria dos sites mais populares da Web não têm no seu núcleo o Java, e sim o PHP (LAMP, sendo mais específico). Isso já prova, na mais cética das hipóteses, que o Java não inventou a escalabilidade, e que outras tecnologias podem sim ser aplicadas em sites com muitos milhões de pages views mensais.

Na verdade, é interessante notar que nesse sentido é o Java que tem que provar seu valor, já que dos sites mais populares, eu só me lembro do Linkedin e dos sites relacionados ao Google que possuem o Java como tecnologia base. Eu imagino que devem existir outros, mas é inegável que ele não é a tecnologia server side dominante na “Web pública”. Isso, ao meu ver, reforça o meu ponto de que o Java não foi feito para a Web, e que não é a melhor opção para a extrema maioria das aplicações Web. Caso contrário, porque tantos sites que deram tão certo passaram longe do Java. Desconhecimento? Duvido muito.

Outro ponto que me faz ver que o Java e a Web são opostos que não se atraem de forma nenhuma é o fato de que todo web designer que eu conheço odeia o Java, e acha que se trata da pior plataforma do mundo para a Web. E aqui eu não estou falando de pilotos de Photoshop/Fireworks, e sim de web designers de verdade, ou seja, pessoas que conhecem tudo sobre coisas como tipografia, teoria das cores e usabilidade, mas que também sabem mais sobre HTML/XHTML, CSS e JavaScript do que qualquer programador que eu já vi.

Esse tipo de profissional, cujo habitat natural é a Web, raramente se dá bem com o Java, pois se trata de uma tecnologia cujo feeling é muito diferente das tecnologias de base da Web. E olha que o melhor web designer que eu conheço sabia programar em C++, Objective-C, PHP e Ruby, mas ainda assim odiou o Java. Ou seja, a desculpa “odeia porque não conseguiu aprender” não é nem de longe válida aqui.

Aliás, esse argumento é péssimo sempre, além de ser um tiro no próprio pé. Se um número grande de desenvolvedores não consegue aprender uma tecnologia que deveria fazer algo comum como aplicações Web com CRUDs e relatórios, devemos, no mínimo, desconfiar que o problema está na tecnologia.

Enfim, o que estou tentando dizer aqui é que não foi exatamente a programação que se tornou mais complicada, e sim que a linguagem mais popular do mundo nos últimos anos possui uma visão mais burocrática do desenvolvimento de software. E por ser a linguagem dominante, essa complexidade atingiu inúmeros desenvolvedores, dando a impressão que desenvolver software hoje é mais difícil. E com isso foi-se embora o que pra mim é o fator mais importante: a diversão.

Elomarns, acho que vc acidentalmente duplicou o seu post. O texto está escrito 2 vezes. Pode editar ali em cima e corrigir?

Aliás, concordando com o que você falou, vi algumas coisas em PHP recentemente que me surpreenderam. Tanto pela evolução da linguagem, quanto do estilo de programar da própria comunidade.

Para citar 3 exemplos: PrestaShop, Wordpress e Joomla.

Todos com códigos bem escritos, fáceis de manter, performáticos e com usuários de escalas consideráveis. E sem tanta burocracia.

ViniGodoy:

Elomarns, acho que vc acidentalmente duplicou o seu post. O texto está escrito 2 vezes. Pode editar ali em cima e corrigir?

Aliás, concordando com o que você falou, vi algumas coisas em PHP recentemente que me surpreenderam. Tanto pela evolução da linguagem, quanto do estilo de programar da própria comunidade.

Para citar 3 exemplos: PrestaShop, Wordpress e Joomla.

Todos com códigos bem escritos, fáceis de manter, performáticos e com usuários de escalas consideráveis. E sem tanta burocracia.

Enfim, já corrigi o post, e desculpe o engano.

Nem sempre é possivel reutilização. Em certas companhias devido as caracteristicas do negocio a reusabilidade é minima mas isos nao impede interoperabilidade de serviços. quem diz isso é thomas erl.

ViniGodoy:

Elomarns, acho que vc acidentalmente duplicou o seu post. O texto está escrito 2 vezes. Pode editar ali em cima e corrigir?

Aliás, concordando com o que você falou, vi algumas coisas em PHP recentemente que me surpreenderam. Tanto pela evolução da linguagem, quanto do estilo de programar da própria comunidade.

Para citar 3 exemplos: PrestaShop, Wordpress e Joomla.

Todos com códigos bem escritos, fáceis de manter, performáticos e com usuários de escalas consideráveis. E sem tanta burocracia.

Não vi esses codigos, eu tinha visto do PHPBB, que é uma bosta, antigos projetos feitos em PHP desanimam muito na linguagem.

Em alguns pontos concordo bastante, talvez o java tenha tentado abraçar um mundo que não lhe pertence, eu quando conheci java pra web amei, estudei varios frameworks, para ver qual era melhor, hoje, não consigo, a lentidao para se iniciar, e ver o resultado e muita, quando vc meche com Ruby e Python e pode fazer seus testes e manipulações de forma mais interativa, fica muito mais prático, hoje não consego programar web em Java sem pensar em como isso ja estaria pronto em Ruby/Python.

Mas para desktop, ainda não estou muito ambientado com essas linguagens, ainda acho java melhor para aplicações rodando em clientes.

rodrigo.lopes:

Após ler o texto, ou melhor, até ler quase o final, pois nao consegui terminar de ler…

a minha humilde opinião:

Nao gosto de pessoas negativas, que texto mais negativo! trabalho há 5 anos com java e ja tive o prazer de trabalhar em otimos projetos…

Pedras no caminho? é claro que teremos, a vida seria maravilhosa se nao existissem…

E aprendemos com nossos erros, crescemos e evoluimos, certo?

bom pelo meno eu penso assim… nunca curti trabalhar com pessoas que so ficassem reclamando, o que eu li foi uma reclamacao total, uma negatividade só, essa foi a minha opinião.

nos dediquemos mais e reclamemos menos.

“Perder menos tempo escrevendo textos longos, e sobrará tempo pra estudar mais…”

Cordeirinho demais você, as pessoas contestam as coisas pq se preocupam, seria muito mais fácil fazer até onde dá e as 18:00 levantar da cadeira e foda-se o projeto, mas as pessoas que eu vejo reclamarem, como o caso da amiga autora do texto, são pessoas que se envolvem no projeto, que querem ver a coisa sair bonita, pois afinal tem meu nome no projeto, não quero ver meu nome em coisa ruim. Esse deve ser o sentimento.

Eu já vi o código do Wordpress… não gostei tb nao…

É organizado pra ser PHP…

Mas tudo é PHP… fica muito ruim…

É a mesma coisa de Java só com JSP…

Se os Rails não tomarem o lugar de Java… acho que de PHP pelo menos toma…

ViniGodoy:

Elomarns, acho que vc acidentalmente duplicou o seu post. O texto está escrito 2 vezes. Pode editar ali em cima e corrigir?

Aliás, concordando com o que você falou, vi algumas coisas em PHP recentemente que me surpreenderam. Tanto pela evolução da linguagem, quanto do estilo de programar da própria comunidade.

Para citar 3 exemplos: PrestaShop, Wordpress e Joomla.

Todos com códigos bem escritos, fáceis de manter, performáticos e com usuários de escalas consideráveis. E sem tanta burocracia.

Em relação às aplicações que você mencionou, eu já olhei o código de apenas uma: o WordPress. Na minha opinião, não há sistema de blogs melhor do que o WordPress. No entanto, se você tiver que mudar algo no código dele precisará de paciência. Da última vez que eu vi, o código era medonho, com classes gigantes responsáveis por todas as letras do MVC. E pelo que tenho lido recentemente, acho que isso não mudou em nada. Sendo assim, acho que você deve ter dado sorte ao olhar o código do WordPress, tendo visto uma parte mais bem escrita do que a média.

Aliás, eu diria que em geral o código de aplicações open source PHP é bem ruim. Além do WordPress, já tive que alterar o código de uma instância do Zen Cart, e posso dizer que a situação ali também era péssima. E como já vi pessoas reclamando da qualidade do código de várias outras aplicações open source feitas com o PHP, e considerando a falta de preparo de boa parte dessa comunidade, eu diria que código ruim é regra nos projetos open source em PHP, e não exceção.

Mas como disse acima, a culpa não é da linguagem, que resolve bem o problema a que se proõe. Além disso, a comunidade PHP aos poucos está amadurecendo. É meio tarde, mas é melhor do que nunca.

rogelgarcia:

Felagund:

Em se falando de hibernate, temos um problema serio, como o Java é Tipificado, e não podemos criar campos em tempo de execução em uma classe (Sim, tem, mas ninguem é loco de ficar usando javassist a torto e adireita, e mesmo assim não é nativo), a solução mais elegante é o ActiveRecord do Rails, na minha opnião, você não se atem a detalhes da base, só se preocupa com detalhes do objeto, tratar os dados, não fica aquele monte de Anotações ou XML.

Creio que o problema não está em escrever os campos, e sim, realizar os mapeamentos ORM. Mesmo com o ActiveRecord, a aplicação continua sendo OO, e o banco relacional.

Um dos problemas que vejo no hibernate é que ele é incompleto e a forma de mapeamento é errada. Exemplo, quando mapeamos um relacionamento @OneToMany. Já definimos no mesmo lugar como é feito o mapeamento e como é feita a persistencia.
Os problemas disso são:

• A forma de mapear, e a forma de persistir, são duas coisas diferentes, logo não deveria estar tudo em apenas uma única anotação.
• O outro problema é que vc define a forma de persistir estaticamente, ou seja, vc só poderá usar essa forma de persistir. Se tiver duas situações no seu programa, o que é comum, onde em um lugar se deseja persistir de uma forma, e em outro lugar de outra forma dependendo da regra de negócio, não será possível.

Por isso sempre faço os mapeamentos não deixando o hibernate fazer nada de forma automática porque isso não funciona. Ao invés disso, executo códigos para persistir de acordo com a necessidade do meu sistema, quando for necessário. Acho que isso resolve alguns problemas que o vini citou…

Vc tem razão. mapeamento e persistência são coisas diferentes.
É por isso que no MiddleHeaven eu não segui essa abordagem. no MH vc consegue persistir objetos sem ter dito nada nem em xml, nem em anotations.
O proprio java é suficiente para fazer o mapeamento e saber se é 1-1 1-N , N-1, etc… Mas existem anotações para coisas como dizer que certa associação é obrigatoria (NotEmpty) e campos não podem ser vazios etc…

O MH parte do conceito de modelo de dominio. Ele constroi esse modelo analizando as classes, mas o modelo pode se criado à mao tb. Diferentes analizadores podem ser usados. Então eu posso misturar as anotações do MH com as do JEE com as do JPA, etc… desde que haja uma analizador que as entenda essa info será colocada no modelo.

Depois a partido do modelo de dominio, o modelo de persistencia é gerado. Este modelo é igual ao de dominio no caso default ( as colunas tem os nomes dos campos,as tabelas as das classes etc…) Tb aqui podemos alterar através de analizadores. Poderiamos, por exemplo, ter coisas como um @Column ou um xml que configura para um banco x espeficio.

Porque o modelo de persistencia do MH não é apenas para banco, então este passo é necessário porque o mesmo modelo de dominio pode ter partes em banco, e partes em xml, ou em memoria,etc…

O Hibernate, embora famoso, não é lá muito bem desenhado… e isso se nota cada vez mais.

sergiotaborda:

O Hibernate, embora famoso, não é lá muito bem desenhado… e isso se nota cada vez mais.

E vai o povo tentando padronizar… faz uma especificação totalmente baseada nesse desenho errado… aff

Esse JPA tá todo errado… heheheh

(Estou curioso para ver como será a persistencia do MH (já li todo o site. heheh)… a um tempo atrás fiz milhoes de rascunhos num projeto para substituir o hibernate, fiz até protótipos… funcionaria bem… sem uma série de limitações que o hibernate tem… Não implementei porque de acordo com meus calculos gastaria pelo menos um ano pra implementar tudo… E tinha outras coisas pra fazer )
(No site vc pergunta se integração com hibernate é necessária: Na minha opnião não, se fizer tudo que o pessoal espera que o hibernate faça… mais algumas coisas… Talvez seja necessário implementar o JPA, apesar de eu achar que JPA é bobagem)

Bom, eu concordo com a autora, mas existe um porém nisso tudo:

O propósito dos Frameworks não é a fácil aprendizagem e sim a agilidade no processo de desenvolvimento.

Por exemplo, se programar MVC usando Servlets e JSP, existem milhões de coisas que vc tem que fazer, em termos de XML e configurações, além de criar taglibs específicas e criar a própria estrutura MVC. Usando um Framework MVC você já tem muitas coisas prontas (Normalmente o “Controller”), porém, isso não quer dizer que você vai pegar o framework e sair usando como se já fosse “amigo” dele de muitos anos, tem que aprender a usar igual e ler sim várias páginas de uma documentação.

Entendo que em um Processo de Desenvolvimento de Software é complicado você parar para ler uma documentação de 500 páginas e, por isso, concordo com a autora.

Agora, discordo um pouco da questão de reutilização. Muitos Frameworks são, sim, reutilizáveis. Inclusive, gosto muito do JSF, que muitos aqui parecem que odeiam. Ele é um Framework que “parece” fácil, pela questão das tags e tudo mais, e quem se prende somente a isso, realmente vai odiar o Framework. Ele é muito mais que isso, tem todo um Ciclo de Vida bastante complicado de entender bem, mas que é extremamente útil.

Enfim, desenvolver java para sites web (portais, sites pessoais, etc…) realmente é um desperdício, agora comparar sistemas que rodam na web feitos em Java com sistemas em PHP é sacanagem. Sem contar que acho o código Java muito mais limpo e legível que o PHP.

Enfim, gostei do artigo, e não quero gerar flames contra quem curte PHP, é apenas minha opinião e não uma verdade absoluta. hehe.

Abraços!

Por que é sacanagem “comparar sistemas que rodam na web feitos em Java com sistemas em PHP”? Até onde eu sei, nenhuma das duas linguagens é inerentemente superior a outra no quesito aplicações Web. E exatamente por isso, a afirmação “acho o código Java muito mais limpo e legível que o PHP” não faz o menor sentido. De quê código Java você está falando? E de que código PHP? É completamente sem sentido afirmar que um código qualquer não especificado escrito em uma linguagem é mais limpo e legível que um outro código qualquer também não especificado escrito em outra linguagem.

Olha, eu nunca li um artigo formal discutindo sobre isso, mas eu acredito que a maior de todas as dicotomias falando-se em desenvolvimento de software é a relação Produtividade x Manutenibilidade

Hà quem acredite que essas coisas podem evoluir juntas, mas esse é o grande pulo do gato, ou melhor, no bordão da Engenharia de Software, essa é a verdadeira Bala de Prata.

Não vou me aprofundar no exame dessa questão até porque parto do principio que vocês sabem do que estou falando por experiencia própria. Nenhuma linguagem é plenamente mais produtiva ou mais mantenível do que outra, apenas são concebidas com propósitos diferentes. Contudo, uma vez que são linguagens Turing completa você pode pender essa balança para o lado que desejar. Muitas vezes essa questão é referida como linguagens fortemente tipadas x linguagens fracamente tipadas. Assunto já exaustivamente discutido.

Quando voce compara Java com Delphi ou PHP voce deve ter essa relação em mente, sempre. Essa noção evitaria comentários ingênuos e flame wars.

O problema é que existe um conjunto de plataformas em que uma aplicação assenta.
Desde de a plataforma fisica até à de aplicação passando pela plataforma alta e a virtual.

Cada tecnllogia de desenvolvimento: java, .net, C, et… lida com este fato de forma diferente. Em C vc acessa a plataforma fisica diretamente e isso torna as coisas muito complicadas porque vc será responsavel de 5 plataformas (desde a fisica à de aplicação)… em java, vc é responsável apenas pela plataforma de aplicação. É uma simplificação enorme.

Só que a plataforma de aplicação não é a aplicação. ela é algo que está abaixo e lhe dá suporte. normalmente o pessoa chama de infra ou “framework” ou algo assim.

Em todas as aplicações vc precisa criar uma plataforma de aplicação. Isto não é optional. a questão é como as pessoas fazem isso. a grande maioria não sabe que isto existe e quando usam o Spring junto com o hibernate e o Struts não enxergam que essas 3 coisas pertecem na plataforma de aplicação. As coisas que vc escolhe por e não por nessa plataforma fazem o desenvolvimento da aplicação em si ser mais facil ou menos.

O segredo é este: tenha uma boa plataforma de aplicação e o desenvolvimento da aplicação será produtivo e de facil manutenção. Não tenha uma boa plataforma de aplicação e será um inferno. Será um inferno também se vc a tem, mas não sabe ( como no exemplo acima do spring-hibernate-struts).

Uma boa plataforma de aplicação leva a uma melhor qualidade interna e portanto a mais produtividade (mais detalhes aqui).

Quando voce compara Java com Delphi ou PHP voce deve ter essa relação em mente, sempre. Essa noção evitaria comentários ingênuos e flame wars.

Comparar Delphi com Java ou PHP não é honesto porque são plataformas virtuais diferentes. Por exemplo , no java vc tem a JVM , em cima dela um web container e em cima dele a aplicação web. Agora faça isso com Delphi… vc terá que criar o web container do zero. É um passo a mais que mata a flexibilidade da plataforma. não é por acaso que hoje em dia apenas se aposta em plataformas abrangentes capazes de fazer todo o tipo de aplicação.
( o exemplo é mais obvio quando comprar delphi e php e java para dispositivos moveis)

Por que é sacanagem “comparar sistemas que rodam na web feitos em Java com sistemas em PHP”? Até onde eu sei, nenhuma das duas linguagens é inerentemente superior a outra no quesito aplicações Web. E exatamente por isso, a afirmação “acho o código Java muito mais limpo e legível que o PHP” não faz o menor sentido. De quê código Java você está falando? E de que código PHP? É completamente sem sentido afirmar que um código qualquer não especificado escrito em uma linguagem é mais limpo e legível que um outro código qualquer também não especificado escrito em outra linguagem.

Bom, como eu falei, isso foi uma opinião pessoal, eu odeio aqueles $_, <?, etc… do PHP, acho que complica a leitura do código. E eu não sei se ainda é assim, mas na época que eu mechi com PHP, chamavam-se métodos de “function”. São coisas que pra alguns não tem importância, mas quando eu passei pra Java, passei a achar mais fácil a leitura de códigos.

Com relação a grandes sistemas, posso estar errado, mas nunca vi um site de banco, por exemplo, desenvolvido em PHP. Banco do Brasil e Itaú, por exemplo, são desenvolvidos em Java.

Só quero deixar claro que é, em partes, uma opinião pessoal. Principalmente a questão da leitura do código. A questão de grandes sistemas também é pessoal porque é a visão que eu tenho, mas posso estar errado.

Abraço!