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ê…
[quote]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ê…[/quote]
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:
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.
É melhor ler pouco e entender bastante do que ler muito e entender quase nada.
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.
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.
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?
Negligenciar nas decisões, nas escolhas nos estudos e posar de vítima é fraco tente evitar chegar a este ponto.
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.
[quote=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:
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.
É melhor ler pouco e entender bastante do que ler muito e entender quase nada.
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.
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.
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?
Negligenciar nas decisões, nas escolhas nos estudos e posar de vítima é fraco tente evitar chegar a este ponto.
Se meter em computação APENAS por dinheiro dá nisso.
…
flws[/quote]
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).
[quote=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.
[/quote]
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:
[quote=FrancoC]miwi
vc fala tanto quanto escreve?
Deus me livre! :roll: [/quote]
Hehehehe.
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?
[quote]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.[/quote]
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”.
[quote=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…”
[/quote]
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.
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:
[quote=MaiqueL]Mas uma coisa é certo o hibernate vai evoluir
e o JSF vai evoluir espero[/quote]
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?!
[quote=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[/quote]
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.
[quote=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.[/quote]
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